Hello, Strange Loop! Strange Loop is one of the first places I spoke almost 10 years ago and I’m so honored to be back here today for the last one. Can we have one more round of applause for the organizers?
你好，Strange Loop！Strange Loop 是我近 10 年前第一次演讲的地方之一，今天能回到这里参加最后一次演讲，我感到非常荣幸。我们能再为主办方鼓掌吗？

I often give talks about things that I'm excited about, or that I think are really fun.
我经常就自己感到兴奋或有趣的事情发表演讲。

But today, I want to talk about something that I'm a little bit mad about, which is that sometimes things that seem like they should be basic take me 10 years or 20 years to learn, way longer than it seems like they should.
但今天，我想谈谈一件让我有点抓狂的事，那就是有时一些看起来应该很基础的东西，我却要花上 10 年或 20 年的时间才能学会，比看起来应该学会的时间要长得多。

One thing that took me a long time to learn was DNS, which is this question of – what’s the IP address for a domain name like example.com? This feels like it should be a straightforward thing.
我花了很长时间才学会 DNS，也就是 "example.com 这样的域名的 IP 地址是什么？感觉这应该是个简单明了的问题。

But seven years into learning DNS, I’d be setting up a website. And I’d feel like things should be working. I thought I understood DNS. But then I’d run into problems, like my domain name wouldn’t work. And I’d wonder – why not? What’s happening?
但在学习 DNS 七年后，我开始建立一个网站。我觉得事情应该是可行的。我以为我了解 DNS。但随后我就会遇到问题，比如我的域名无法使用。我就会想--为什么不行？发生了什么事？

And sometimes this would feel kind of personal! This shouldn't be so hard for me! I should understand this already. It's been seven years!
有时，这会让人觉得有点私人！这对我来说不应该这么难！我应该已经明白了已经七年了

And this "it's just me" attitude is often encouraged -- when I write about finding things hard to learn on the Internet, Internet strangers will sometimes tell me: "yeah, this is easy! You should get it already! Maybe you're just not very smart!"
这种 "这只是我的问题 "的态度常常得到鼓励--当我写到在互联网上发现很难学习的东西时，互联网上的陌生人有时会告诉我："是啊，这很容易！你应该已经懂了！也许你只是不太聪明！"

But luckily I have a pretty big ego so I don't take the internet strangers too seriously. And I have a lot of patience so I'm willing to keep coming back to a topic I'm confused about. There were maybe four different things that were going wrong with DNS in my life and eventually I figured them all out.
但幸运的是，我有很强的自尊心，所以我不会把网络上的陌生人太当回事。而且我很有耐心，所以我愿意不断地回到我困惑的话题上来。在我的生活中，DNS 可能有四种不同的问题，最终我都解决了。

So, hooray! I understood DNS! I win! But then I see some of my friends struggling with the exact same things.
所以，万岁！我听懂了 DNS！我赢了！但后来我看到我的一些朋友也在为同样的事情苦恼。

They're wondering, hey, my DNS isn't working. Why not?
他们会想，嘿，我的 DNS 不工作了。为什么不行？

And it doesn't end. We're still having the same problems over and over and over again. And it's frustrating! It feels redundant! It makes me mad. Especially when friends take it personally, and they feel like "hey I should really understand this already".
这一切并没有结束。我们仍在一次又一次地遇到同样的问题。真让人沮丧感觉多余这让我很生气。尤其是当朋友们把它当成个人问题时，他们会觉得 "嘿，我真的应该已经明白了"。

Because everyone is going through this. From the sounds of recognition I hear, I think a lot of you have been through some of these same problems with DNS.
因为每个人都经历过这种情况。从我听到的认可声中，我认为你们中的很多人都经历过 DNS 的一些相同问题。

I got so mad about this that I decided to make it my job.
我为此非常生气，决定把这当成我的工作。

I started a little publishing company called Wizard Zines where --
我创办了一家名为 "Wizard Zines "的小型出版公司。

(applause)  （掌声）

Wow. Where I write about some of these topics and try to demystify them.
哇我写了一些关于这些主题的文章，并试图揭开它们的神秘面纱。

Here are a few of the zines I've published. I want to talk today about a few of these topics and what makes them so hard and how we can make them easier.
以下是我出版过的几本杂志。我今天想谈谈其中的几个主题，它们为何如此艰难，以及我们如何才能让它们变得更容易。

We're going to talk about bash, HTTP, SQL, and DNS.
我们将讨论 bash、HTTP、SQL 和 DNS。

For each of them, we're going to talk a little bit about:
接下来，我们将逐一介绍：

a. what's so hard about it?
A. 这有什么难的？

b. what are some things we can do to make it a little bit easier for each other?
B. 我们可以做些什么来让彼此更轻松一些？

Let's start with Bash.
让我们从巴什开始。

What's so hard about it?
这有什么难的？

So, bash is a programming language, right? But it's one of the weirdest programming languages that I work with.
那么，bash 是一种编程语言，对吗？但它却是我使用过的最奇怪的编程语言之一。

To understand why it’s weird, let’s do a little small demo of bash.
为了理解为什么会出现这种奇怪的情况，让我们做一个小小的 bash 演示。

First, let's run this script, bad.sh:
首先，让我们运行这个脚本 bad.sh ：

mv ./*.txt /tmmpp
echo "success!"

This moves a file and prints "success!". And with most of the programming languages that I use, if there's a problem, the program will stop.
这将移动一个文件并打印 "成功！"。在我使用的大多数编程语言中，如果出现问题，程序就会停止。

[laughter from audience]
[观众笑声]

But I think a lot of you know from maybe sad experience that bash does not stop, right? It keeps going. And going… and sometimes very bad things happen to your computer in the process.
但我想你们中的很多人都有过这样的悲惨经历，那就是狂欢不会停止，对吗？它一直在运行。在这个过程中，你的电脑有时会发生非常糟糕的事情。

When I run this program, here's the output:
当我运行这个程序时，输出结果如下：

mv: cannot stat './*.txt': No such file or directory
success!

It didn't stop after the failed mv.
在 mv 失败之后，它并没有停止。

Eventually I learned that you can write set -e at the top of your program, and that will make bash stop if there's a problem.
最后我了解到，你可以在程序顶端写 set -e ，这样 bash 就会在出现问题时停止运行。

When we run this new program with set -e at the top, here's the output:
当我们运行这个新程序，并在顶部输入 set -e 时，输出结果如下：

mv: cannot stat './*.txt': No such file or directory

Great. We're happy. Everything is good. But every time I think I've learned everything that go wrong with bash, I'll find out -- surprise! There are more bad things that can happen! Let's look at another program as an example.
太好了我们很高兴。一切都很好。但每当我以为我已经了解了 Bash 的所有问题时，我就会发现--惊喜！还有更多糟糕的事情会发生！让我们以另一个程序为例。

Here we've put our code in a function. And if the function fails, we want to echo "failed".
在这里，我们将代码放在一个函数中。如果函数失效，我们要回显 "failed"（失败）。

So use set -e at the beginning, and you might think everything should be okay.
因此，在开始时使用 set -e ，你可能会认为一切都会好起来。

But if we run it... this is the output we get
但如果我们运行它......得到的输出结果是这样的

mv: cannot stat './*.txt': No such file or directory
success

We get the "success" message again! It didn't stop, it just kept going. This is because the "or" (|| echo "failed") globally disables set -e in the function.
我们再次收到 "成功 "信息！它没有停止，而是继续运行。这是因为函数中的 "或"（ || echo "failed" ）全面禁用了 set -e 。

Which is certainly not what I wanted, and not what I would expect. But this is not a bug in bash, it's is the documented behavior.
这当然不是我想要的，也不是我所期望的。但这并不是 bash 的错误，而是文件记录的行为。

And I think one reason this is tricky is a lot of us don't use bash very often. Maybe you write a bash script every six months and don't look at it again.
我认为这很棘手的一个原因是，我们很多人并不经常使用 bash。也许你每半年写一个 bash 脚本，然后就不再看它了。

When you use a system very infrequently and it's full of a lot of weird trivia and gotchas, it's hard to use the system correctly.
当你很少使用一个系统，而它又充满了许多奇怪的琐事和麻烦时，你就很难正确地使用这个系统。

So how can we make this easier? What can we do about it?
那么，我们怎样才能让这一切变得更容易呢？我们能做些什么？

One thing that I sometimes hear is -- a newcomer will say "this is hard", and someone more experienced will say "Oh, yeah, it's impossible to use bash. Nobody knows how to use it."
我有时会听到这样一种说法：新手会说 "这很难"，而更有经验的人会说 "哦，是啊，用 bash 是不可能的。没人知道怎么用它"。

But I would say this is factually untrue. How many of you are using bash?
但我要说，这与事实不符。你们中有多少人在使用 bash？

A lot of us ARE using it! And it doesn't always work perfectly, but often it gets the job done.
我们很多人都在使用它！它并不总是完美无缺，但往往能完成工作。

We have a lot of bash programs that are mostly working, and there’s a big community of us who are using bash mostly successfully despite all the problems.
我们有很多 bash 程序，它们大部分都能正常工作，而且我们有一个庞大的社区，尽管存在各种问题，但大部分人都能成功地使用 bash。

The way I think this is -- you have some people on the left in this diagram who are confused about bash, who think it seems awful and incomprehensible.
我的看法是 -- 在这个图表中，有些左翼人士对 "抨击 "感到困惑，他们认为 "抨击 "看起来很可怕，难以理解。

And some people on the right who know how to make the bash work for them, mostly.
还有一些右翼人士，他们大多知道如何让 "抨击 "为他们所用。

So how do we move people from the left to the right, from being overwhelmed by a pile of impossible gotchas to being able to mostly use the system correctly?
那么，我们怎样才能让人们从 "左 "到 "右"，从被一大堆不可能解决的问题难倒，到基本上能够正确使用系统呢？

Well, bash has a giant pile of trivia to remember. But who’s good at remembering giant piles of trivia?
狂欢有一大堆琐事要记。但谁又能记住一大堆琐事呢？

Not me! I can’t memorize all of the weird things about bash. But computers! Computers are great at memorizing trivia!
我不会我不可能记住所有关于 bash 的奇怪东西。但是电脑电脑很擅长记忆琐事

And for bash, we have this incredible tool called shellcheck.
对于 bash，我们有一个不可思议的工具，叫做 shellcheck。

[ Applause ]  [ 鼓掌 ]

Yes! Shellcheck is amazing! And shellcheck knows a lot of things that can go wrong and can tell you "oh no, you don't want to do that. You're going to have a bad time."
是的！Shellcheck 太棒了！Shellcheck 知道很多可能出错的事情 还能告诉你 "哦，不，你不会想那么做的你会有一段糟糕的时光。"

I'm very grateful for shellcheck, it makes it much easier for me to write tiny bash scripts from time to time.
我非常感谢 shellcheck，它让我时不时写一些小的 bash 脚本变得容易多了。

Now let's do a shellcheck demo!
现在我们来做一个 shellcheck 演示！

$ shellcheck -o all bad-again.sh
In bad-again.sh line 7:
f || echo "failed!"
^-- SC2310 (info): This function is invoked in an || condition so set -e will be disabled. Invoke separately if failures should cause the script to exit.

Shellcheck gives us this lovely error message. The message isn't completely obvious on its own (and this check is only run if you invoke shellcheck with -o all). But shellcheck tells you "hey, there's this problem, maybe you should be worried about that".
Shellcheck 给了我们这个可爱的错误信息。这条信息本身并不十分明显（而且只有在用 -o all 调用 shellcheck 时才会运行这项检查）。但 shellcheck 会告诉你 "嘿，有这个问题，也许你应该担心一下"。

And I think it's wonderful that all these tips live in this linter.
我认为，把所有这些小窍门都放在这个夹层里真是太好了。

I'm not trying to tell you to write linters, though I think that some of you probably will write linters because this is that kind of crowd.
我并不是想让你们写流水账，尽管我认为你们中的一些人可能会写流水账，因为这是一群这样的人。

I've personally never written a linter, and I'm definitely not going to create something as cool as shellcheck!
我个人从来没有写过衬垫，也绝对不会创造出像 shellcheck 一样酷的东西！

But instead, the way I write linters is I tell people about shellcheck from time to time and then I feel a little like I invented shellcheck for those people. Because some people didn't know about the tool until I told them about it!
但相反，我写 linters 的方式是时不时地向人们介绍 shellcheck，然后我觉得自己有点像为这些人发明了 shellcheck。因为在我告诉他们之前，有些人并不知道这个工具！

I didn't find out about shellcheck for a long time and I was kind of mad about it when I found out. I felt like -- excuse me? I could have been using shellcheck this whole time? I didn't need to remember all of this stuff in my brain?
我很久才知道贝壳检查的事，知道后我有点生气。我觉得 -- 对不起？我本可以一直使用 shellcheck 的？我不需要把这些东西都记在脑子里？

So I think an incredible thing we can do is to reflect on the tools that we're using to reduce our cognitive load and all the things that we can't fit into our minds, and make sure our friends or coworkers know about them.
因此，我认为我们可以做的一件不可思议的事情，就是反思我们用来减少认知负荷的工具，以及所有我们脑子里装不下的东西，并确保我们的朋友或同事知道这些工具。

I also like to warn people about gotchas and some of the terrible things computers have done to me.
我还喜欢提醒人们注意一些问题，以及电脑对我做过的一些可怕的事情。

I think this is an incredibly valuable community service. The example I shared about how set -e got disabled is something I learned from my friend Jesse a few weeks ago.
我认为这是一项非常有价值的社区服务。我分享的 set -e 被禁用的例子是我几周前从朋友杰西那里学到的。

They told me how this thing happened to them, and now I know and I don't have to go through it personally.
他们告诉我这件事是如何发生在他们身上的，现在我知道了，我不必再亲身经历了。

One way I see people kind of trying to share terrible things that their computers have done to them is by sharing "best practices".
我看到人们试图分享电脑对他们造成的可怕影响，其中一种方式就是分享 "最佳实践"。

But I really love to hear the stories behind the best practices!
但我真的很喜欢听最佳实践背后的故事！

If someone has a strong opinion like "nobody should ever use bash", I want to hear about the story! What did bash do to you? I need to know.
如果有人有 "谁都不应该使用 bash "这样的强烈观点，我想听听他的故事！bash 对你做了什么？我需要知道

The reason I prefer stories to best practices is if I know the story about how the bash hurt you, I can take that information and decide for myself how I want to proceed.
比起最佳实践，我更喜欢故事，因为如果我知道 "撞击 "是如何伤害你的，我就可以利用这些信息，自己决定如何继续。

Maybe I feel like -- the computer did that to you? That's okay, I can deal with that problem, I don't mind.
也许我觉得是电脑把你弄成这样的？没关系，我能解决这个问题，我不介意。

Or I might instead feel like "oh no, I'm going to do the best practice you recommended, because I do not want that thing to happen to me".
或者，我可能会觉得 "哦，不，我要按照你推荐的最佳做法去做，因为我不希望这种事情发生在我身上"。

These bash stories are a great example of that: my reaction to them is "okay, I'm going to keep using bash, I'll just use shellcheck and keep my bash scripts pretty simple". But other people see them and decide "wow, I never want to use bash for anything, that's awful, I hate it".
这些 bash 故事就是一个很好的例子：我看到后的反应是 "好吧，我还是继续用 bash，我只用 shellcheck，让我的 bash 脚本保持简单"。但其他人看到这些故事，就会觉得 "哇，我再也不想用 bash 做任何事情了，太可怕了，我讨厌它"。

Different people have different reactions to the same stories and that's okay.
不同的人对同样的故事有不同的反应，这没有关系。

That's all for bash. Next up we're gonna talk about HTTP.
这就是 bash 的全部内容。接下来我们来谈谈 HTTP。

I was talking to Marco Rogers at some point, many years ago, and he mentioned some new developers he was working with were struggling with HTTP.
多年前，我曾与马可-罗杰斯（Marco Rogers）交谈，他提到与他合作的一些新开发人员在 HTTP 方面遇到了困难。

And at first, I was a little confused about this -- I didn't understand what was hard about HTTP.
起初，我对此有些困惑 -- 我不明白 HTTP 难在哪里。

The way I was thinking about it at the time was that if you have an HTTP response, it has a few parts: a response code, some headers, and a body.
我当时的想法是，如果你有一个 HTTP 响应，它有几个部分：一个响应代码、一些标头和一个正文。

I felt like -- that's a pretty simple structure, what's the problem? But of course there was a problem, I just couldn't see what it was at first.
我觉得 -- 这个结构很简单，有什么问题呢？但问题当然是有的，只是我一开始看不出来。

So, I talked to a friend who was newer to HTTP. And they asked "why does it matter what headers you set?"
于是，我和一位刚接触 HTTP 的朋友聊了起来。他们问："为什么设置什么标头很重要？

And I said: "well, the browser..."
我说"浏览器......"

But then I thought... the browser?
但我转念一想......浏览器？

the browser?  浏览器？

The browser!  浏览器

Firefox is 20 million lines of code! It's been evolving since the '90s. There have been as I understand it, 1 million changes to the browser security model as people have discovered new and exciting exploits and the web has become a scarier and scarier place.
火狐浏览器有 2000 万行代码！自 90 年代以来，它一直在不断发展。据我所知，随着人们不断发现新的令人兴奋的漏洞，网络变得越来越可怕，浏览器的安全模式已经发生了 100 万次变化。

The browser is really a lot to understand.
要了解浏览器的内容还真不少。

One trick for understanding why a topic is hard is -- if the implementation if the thing involves 20 million lines of code, maybe that's why people are confused!
要理解一个课题为什么难，有一个诀窍，那就是--如果这个课题的实现需要两千万行代码，也许这就是人们感到困惑的原因！

Though that 20 million lines of code also involves CSS and JS and many other things that aren't HTTP, but still.
虽然这 2000 万行代码还涉及 CSS、JS 和许多其他非 HTTP 的东西，但仍然如此。

Once I thought of it in terms of how complex a modern web browser is, it made so much more sense! Of course newcomers are confused about HTTP if you have to understand what the browser is doing!
我一想到现代网络浏览器的复杂性，就觉得有道理多了！如果你必须了解浏览器在做什么，新手当然会对 HTTP 感到困惑！

Then my problem changed from "why is this hard?" to "how do I explain this at all?"
然后，我的问题就从 "这有什么难的？"变成了 "我该怎么解释呢？"

So how do we make it easier? How do we wrap our minds around this 20 million lines of code?
那么，我们该如何让它变得更容易呢？如何让我们的思维围绕着这 2000 万行代码运转？

One way I think about this for HTTP is: here are some of the HTTP request headers. That's kind of a big list there are 43 headers there.
我对 HTTP 的一种理解是：这里是 HTTP 请求的一些标头。这是一个很大的列表，共有 43 个标头。

There are more unofficial headers too.
还有更多的非官方标题。

My brain does not contain all of those headers, I have no idea what most of them are.
我的大脑里没有这些标题，我不知道其中大部分是什么。

When I think about trying to explain big topics, I think about -- what is actually in my brain, which only contains a normal human number of things?
当我试图解释一些大的话题时，我就会想 -- 我的大脑里究竟有什么，而我的大脑里只有正常人数量的东西？

This is a comic I drew about HTTP request headers. You don't have to read the whole thing. This has 15 request headers.
这是我画的一幅关于 HTTP 请求头的漫画。你不必读完它。这里有 15 个请求头。

I wrote that these are "the most important headers", but what I mean by "most important" here is that these are the ones that I know about and use. It's a subjective list.
我写道，这些是 "最重要的标头"，但我这里所说的 "最重要 "是指我所知道并使用的标头。这是一个主观的列表。

I wrote about 12 words about each one, which I think is approximately the amount of information about each header that lives in my mind.
我为每个标题写了大约 12 个字，我想这大概是我脑海中关于每个标题的信息量。

For example I know that you can set Accept-Encoding to gzip and then you might get back a compressed response. That's all I know, and that's usually all I need to know!
例如，我知道你可以将 Accept-Encoding 设置为 gzip ，然后你可能会得到一个压缩响应。我只知道这么多，通常我只需要知道这么多！

This very small set of information is working pretty well for me.
这一小部分信息对我来说非常有用。

The general way I think about this trick is "turn a big list into a small list".
我对这个技巧的一般理解是 "把大名单变成小名单"。

Turn the set of EVERY SINGLE THING into just the things I've personally used. I find it helps a lot.
把所有的东西都变成我自己用过的东西。我发现这对我帮助很大。

Another example of this "turn a big list into a small list" trick is command line arguments.
另一个 "化大为小 "的例子是命令行参数。

I use a lot of command line tools, the number of arguments they have can be overwhelming, and I've written about them a fair amount over the years.
我使用过很多命令行工具，它们的参数数量可能会让我应接不暇，多年来我也写过不少关于它们的文章。

Here are all the flags for grep, from its man page. That's too much! I've been using grep for 20 years but I don't know what all that stuff is.
下面是 grep 的所有标记，摘自其 man 页面。太多了！我用 grep 已经有 20 年了，但我不知道这些都是什么。

But when I look at the grep man page, this is what I see.
但当我查看 grep man 页面时，看到的却是这样的内容。

I think it's very helpful to newcomers when a more experienced person says "look, I've been using this system for a while, I know about 7 things about it, and here's what they are".
我认为，当一个更有经验的人说 "听着，我已经使用这个系统有一段时间了，我知道关于它的七件事，它们是什么 "时，对新人来说是非常有帮助的。

We're just pruning those lists down to a more human scale. And it can even help other more experienced people -- often someone else will know a slightly different set of 7 things from me.
我们只是把这些清单删减得更人性化。它甚至还能帮助其他更有经验的人--经常会有人知道与我略有不同的 7 件事。

But what about the stuff that doesn't fit in my brain?
但我脑子里装不下的东西怎么办？

Because I have a few things about HTTP stored in my brain. But sometimes I need other information which is hard to remember, like maybe the exact details of how CORS works.
因为我的大脑中已经储存了一些关于 HTTP 的信息。但有时我还需要其他难以记住的信息，比如 CORS 工作原理的具体细节。

And so, that’s where we come to references. Where do we find the information that we can’t remember?
因此，我们就需要参考资料。我们从哪里找到记不住的信息？

I often have trouble finding the right references.
我经常找不到合适的参考资料。

For example I've been trying to learn CSS off and on for 20 years. I've made a lot of progress -- it's going well!
例如，20 年来，我一直在断断续续地尝试学习 CSS。我已经取得了很大的进步--进展顺利！

But only in the last 2 years or so I learned about this wonderful website called CSS Tricks.
但直到最近两年左右，我才了解到这个名为 CSS 技巧的奇妙网站。

And I felt kind of mad when I learned about CSS Tricks! Why didn't I know about this before? It would have helped me!
当我了解到 CSS 技巧时，我感到有点生气！为什么我以前不知道？它本可以帮到我的！

But anyway, I'm happy to know about CSS Tricks now. (though sadly they seem to have stopped publishing in April after the acquisition, I'm still happy the older posts are there)
但无论如何，我很高兴现在知道了 CSS Tricks。(虽然不幸的是，他们似乎在四月份被收购后就停止了发布，但我还是很高兴能看到以前的文章）。

For HTTP, I think a lot of us use the Mozilla Developer Network.
对于 HTTP，我想我们很多人都使用 Mozilla Developer Network。

Another HTTP reference I love is the official RFC, RFC 9110 (also 9111, 9112, 9113, 9114)
我喜欢的另一个 HTTP 参考资料是官方 RFC RFC 9110（还有 9111、9112、9113 和 9114）。

It's a new authoritative reference for HTTP and it was written just last year, in 2022! They decided to organize all the information really nicely. So if you want to know exactly what the Connection header does, you can look it up.
这是一本全新的 HTTP 权威参考书，去年（2022 年）刚刚编写完成！他们决定将所有信息整理得井井有条。因此，如果你想知道 Connection 标头的具体作用，你可以查找它。

This is not really my top reference. I'm usually on MDN. But I really appreciate that it's available.
这并不是我的首选参考资料。我通常使用 MDN。但我真的很感谢它的存在。

So I love to share my favorite references.
因此，我喜欢分享我最喜欢的参考资料。

I do sometimes find it tempting to kind of lie about references. Not on purpose. But I'll see something on the internet, and I'll think it's kind of cool, and tell a friend about. But then my friend might ask me -- "when have you used this?" And I'll have to admit "oh, never, I just thought it seemed cool".
有时，我确实会在推荐信上撒谎。不是故意的。但我会在网上看到一些东西，觉得很酷，然后告诉朋友。但朋友可能会问我 "你什么时候用过这个？"而我不得不承认 "哦，从来没有，我只是觉得它看起来很酷"。

I think it's important to be honest about what the references that I'm actually using in real life are. Even if maybe the real references I use are a little "embarrassing", like maybe w3schools or something.
我认为重要的是，要诚实地说出我在现实生活中实际使用的参考资料是什么。即使我真正使用的参考资料有点 "尴尬"，比如 w3schools 或其他什么。

So that’s HTTP! Next we’re going to talk about SQL.
这就是 HTTP！接下来我们来谈谈 SQL。

The case of the mysterious execution order.
神秘的执行令案例。

I started thinking about SQL because someone mentioned they're trying to learn SQL. I get most of my zine ideas that way, one person will make an offhand comment and I'll decide "ok, I'm going to spend 4 months writing about that". It's a weird process.
我开始考虑 SQL，是因为有人提到他们正在尝试学习 SQL。我的大部分杂志创意都是这样得来的：一个人随口说了一句话，我就决定 "好吧，我要花 4 个月来写这个"。这个过程很奇怪。

So I was wondering -- what's hard about SQL? What gets in the way of trying to learn that?
所以我想知道 -- SQL 难在哪里？学习 SQL 会遇到什么困难？

I want to say that when I'm confused about what's hard about something, that's a fact about me. It's not usually that the thing is easy, it's that I need to work on understanding what's hard about it. It's easy to forget when you've been using something for a while.
我想说，当我对某件事情的难点感到困惑时，这就是我的事实。通常情况下，并不是这件事很容易，而是我需要努力去理解它的难处。用久了就容易忘记。

So, I was used to reading SQL queries. For example this made up query that tries to find people who own exactly two cats. It felt straightforward to me, SELECT, FROM, WHERE, GROUP BY.
因此，我习惯于阅读 SQL 查询。例如，这个编造的查询试图找到拥有两只猫的人。我觉得它很简单，SELECT、FROM、WHERE、GROUP BY。

But then I was talking to a friend about these queries who was new to SQL. And my friend asked -- what is this doing?
但后来我和一位刚接触 SQL 的朋友聊起这些查询时，他问我 -- 这是在做什么？我的朋友问 -- 这是在做什么？

I thought, hmm, fair point.
我想，嗯，有道理。

And I think the point my friend was making was that the order that this SQL query is written in, is not the order that it actually happens in. It happens in a different order, and it's not immediately obvious what that is.
我想我朋友想说的是，这个 SQL 查询的编写顺序与实际发生的顺序不同。它是以另一种顺序发生的，而这种顺序并不是一眼就能看出来的。

So how do we make this easier?
那么，我们该如何让这一切变得更容易呢？

I like to think about: what does the computer do first? What actually happens first chronologically?
我喜欢思考：计算机先做什么？按照时间顺序，究竟是什么先发生？

Computers actually do live in the same timeline as us. Things happen. Things happen in an order. So what happens first?
实际上，计算机和我们生活在同一时间线上。事情会发生。事情的发生是有顺序的。那么，先发生什么？

The way I think about an SQL query is: is you start with a table like cats.
我对 SQL 查询的理解是：从 cats 这样的表开始。

Then maybe you filter it, you remove some stuff.
然后，也许你会过滤一下，去掉一些东西。

Then you make some groups.
然后再分组。

Then you filter the groups, remove some of them.
然后过滤分组，删除其中一些。

Then you do some aggregation. There’s two things in each group.
然后进行汇总。每组有两样东西。

And you sort it.
然后进行分类。

And you can also limit the results.
您还可以限制结果。

So, that's how I think about SQL. The way a query runs is first FROM, then WHERE, GROUP BY, HAVING, SELECT, ORDER BY, LIMIT.
这就是我对 SQL 的理解。查询的运行方式首先是 FROM，然后是 WHERE、GROUP BY、HAVING、SELECT、ORDER BY、LIMIT。

At least conceptually. Real life databases have optimizations and it's more complicated than that. But this is the mental model that I use most of the time and it works for me. Everything is in the same order as you write it, except SELECT is fifth.
至少在概念上是这样。现实生活中的数据库需要优化，比这更复杂。但这是我大多数时候使用的思维模型，对我来说很有效。除了 SELECT 是第五个之外，其他的顺序都和你写的一样。

I’ve really gotten a lot out of this trick where you try to tell the chronological story of what the computer is doing. I want to talk about a couple other examples.
我真的从这个技巧中得到了很多启发，你可以尝试按时间顺序讲述计算机正在做的事情。我还想谈谈其他几个例子。

One is CORS, in HTTP.
一种是 HTTP 中的 CORS。

This comic is way too small to read on the slide. But the idea is if you're making a cross-origin request in your browser, you can write down every communication that's happening between your browser and the server, in chronological order.
这幅漫画太小，无法在幻灯片上阅读。但它的意思是，如果你在浏览器中进行跨源请求，你可以按时间顺序记下浏览器和服务器之间发生的每一次通信。

And I think writing down everything in chronological order makes it a lot easier to understand and more concrete.
我认为，按照时间顺序写下所有内容会更容易理解，也更具体。

"What happens in chronological order?" is a very straightforward structure, which is what I like about it. "What happens first?" feels like it should be easy to answer. But it's not!
"按时间顺序会发生什么？"是一个非常直截了当的结构，这也是我喜欢它的原因。"先发生什么？"感觉应该很容易回答。但事实并非如此！

I've found that it's actually very hard to know what our computers is doing, and it's a really fun question to explore.
我发现，其实很难知道我们的计算机在做什么，而这是一个非常有趣的探索问题。

As an example of how this is hard: I wrote a blog post recently called "Behind Hello World on Linux". It's about what happens when you run "hello world" on a Linux computer. I wrote a bunch about it, and I was really happy with it.
举例说明这有多难：我最近写了一篇博文，名为 "Linux 上 Hello World 的背后"。这篇文章讲述了在 Linux 计算机上运行 "hello world "时会发生什么。我写了一大堆关于它的内容，我对它非常满意。

But after I wrote the post, I thought -- haven't I written about this before? Maybe 10 years ago?
但写完这篇文章后，我又想 -- 我以前不是写过这篇文章吗？也许是十年前？

And sure enough, I'd tried to write a similar post 10 years before.
果然，10 年前我也曾尝试写过类似的文章。

I think this is really cool. Because the 2013 version of this post was about 6 times shorter. This isn't because Linux is more complicated than it was 10 years ago -- I think everything in the 2023 post was probably also true in 2013. The 2013 post just has a lot less information in it.
我觉得这真的很酷。因为这篇文章的 2013 年版本大约短了 6 倍。这并不是因为 Linux 比 10 年前更复杂了，我认为 2023 年版本中的所有内容在 2013 年可能也是如此。只是 2013 年版本的信息量要少得多。

The reason the 2023 post is longer is that I didn't know what was happening chronologically on my computer in 2013 very well, and in 2023 I know a lot more. Maybe in 2033 I'll know even more!
2023 年的文章之所以更长，是因为 2013 年我还不太清楚电脑上按时间顺序发生了什么，而到了 2023 年，我知道的就更多了。也许到了 2033 年，我会知道得更多！

I think a lot of us -- like me in 2013 and honestly me now, often don't know the facts of what's happening on our computers. It's very hard, which is what makes it such a fun question to try and discuss.
我认为，我们中的很多人--比如 2013 年的我和现在的我--经常不知道电脑上发生了什么。这很难，所以才会有这样一个有趣的问题来尝试和讨论。

I think it's cool that all of us have different knowledge about what is happening chronologically on our computers and we can all chip in to this conversation.
我认为，我们每个人对电脑上按时间顺序发生的事情都有不同的了解，我们都可以参与到这场对话中来，这很酷。

For example when I posted this blog post about Hello World on Linux, some people mentioned that they had a lot of thoughts about what happens exactly in your terminal, or more details about the filesystem, or about what's happening internally in the Python interpreter, or any number of things. You can go really deep.
例如，当我发布这篇关于 Linux 上的 Hello World 的博文时，有些人提到他们对终端中到底发生了什么、文件系统的更多细节、Python 解释器内部发生了什么等问题有很多想法。你可以想得非常深入。

I think it's just a really fun collaborative question.
我认为这只是一个非常有趣的合作问题。

I've seen "what happens chronologically?" work really well as an activity with coworkers, where you're ask: "when a request comes into this API endpoint we run, how does that work? What happens?"
我见过把 "按时间顺序发生了什么？"作为与同事一起开展的活动，效果非常好，你会被问到："当一个请求进入我们运行的 API 端点时，它是如何工作的？会发生什么？"

What I've seen is that someone will understand some part of the system, like "X happens, then Y happens, then it goes over to the database and I have no idea how that works". And then someone else can chime in and say "ah, yes, with the database A B C happens, but then there's a queue and I don't know about that".
我见过的情况是，有人会理解系统的某些部分，比如 "X 发生了，然后 Y 发生了，然后它转到数据库，我不知道它是如何工作的"。然后其他人会插话说："啊，是的，在数据库中会发生 A B C，但随后会有一个队列，我不知道这个"。

I think it's really fun to get together with people who have different specializations and try to make these little timelines of what the computers are doing. I've learned a lot from doing that with people.
我认为，与不同专业的人聚在一起，尝试制作计算机工作的小时间表，真的很有趣。我从与人合作中学到了很多。

That's all for SQL.
这就是 SQL 的全部内容。

So, now we’ve arrived at DNS which is where we started the talk.
现在，我们来到了 DNS，这也是我们开始讨论的地方。

Even though I struggled with DNS. Once I got figured it out, I felt like "dude, this is easy!". Even though it just took me 10 years to learn how it works.
尽管我在 DNS 上费了不少劲。一旦我弄明白了，我就觉得 "伙计，这很容易！"。尽管我花了 10 年时间才学会它是如何工作的。

But of course, DNS was pretty hard for me to learn. So -- why is that? Why did it take me so long?
当然，DNS 对我来说也很难学。那么，这是为什么呢？为什么我花了那么长时间？

So, I have a little chart here of how I think about DNS.
因此，我这里有一张小图表，说明我是如何看待 DNS 的。

You have your browser on the left. And over on the right there's the authoritative nameservers, the source of truth of where the DNS records for a domain live.
左边是浏览器。右边是权威域名服务器，它是域名 DNS 记录的真实来源。

In the middle, there's a function that you call and a cache. So you have browser, function, cache, source of truth.
中间有一个你调用的函数和一个缓存。这样就有了浏览器、函数、缓存、真相源。

One problem is that there are a lot of things in this diagram that are totally hidden from you.
一个问题是，这幅图中有很多东西是完全不为人知的。

The library code that you're using where you make a DNS request -- there are a lot of different libraries you could be using, and it's not straightforward to figure out which one is being used. That was the source of some of my confusion.
你在进行 DNS 请求时使用的库代码 -- 你可能使用了很多不同的库，要弄清楚使用的是哪个库并不简单。这就是我感到困惑的地方。

There's a cache which has a bunch of cached data. That's invisible to you, you can't inspect it easily and you have no control over it. that
缓存中有大量缓存数据。你看不到它，无法轻易检查它，也无法控制它。

And there's a conversation between the cache and the source of truth, these two red arrows which also you can't see at all.
在缓存和真相源（这两个你完全看不到的红色箭头）之间有一场对话。

So this is kind of tough! How are you supposed to develop an intuition for a system when it's mostly things that are completely hidden from you? Feels like a lot to expect.
所以这有点困难！当一个系统中的大部分东西对你来说都是完全隐藏的时候，你该如何培养对这个系统的直觉呢？感觉期望很高。

So, what do we do about this?
那么，我们该怎么办呢？

So: let's talk about these red arrows on the right.
那么：让我们来谈谈右边的这些红色箭头。

We have our cache and then we have the source of truth. This conversation is normally hidden from you because you often don't control either of these servers. Usually they're too busy doing high-performance computing to report to you what they're doing.
我们有缓存，也有真相源。这种对话通常不为你所知，因为你通常无法控制这两台服务器。它们通常忙于高性能计算，无法向你报告它们在做什么。

But I thought: anyone can write an authoritative nameserver! In particular, I could write one that reports back every single message that it receives to its users. So, with my friend Marie, we wrote a little DNS server.
但我想：任何人都可以编写一个权威的名称服务器！尤其是，我可以写一个能向用户报告它收到的每一条信息的服务器。于是，我们和我的朋友玛丽一起编写了一个小小的 DNS 服务器。

(demo of messwithdns.net)
（messwithdns.net 演示）

This is called Mess With DNS. The idea is I have a domain name and you can do whatever you want with it. We're going to make a DNS record called strangeloop, and we're going to make a CNAME record pointing at orange.jvns.ca, which is just a picture of an orange. Because I like oranges.
这就是所谓的 "乱用 DNS"。意思是我有一个域名，你可以对它为所欲为。我们要创建一个名为 strangeloop 的 DNS 记录，然后创建一个指向 orange.jvns.ca 的 CNAME 记录，这只是一张橙子的图片。因为我喜欢橙子。

And then over here, every time a request comes in from a resolver, this will -- this will report back what happened. So, if we click on this link, we can see -- a Canadian DNS resolver, which is apparently what my browser is configured to use, is requesting an IPv4 record and an IPv6 record, A and AAAA.
然后在这里，每当一个解析器发出请求，这里就会 -- 这里就会报告发生了什么。因此，如果我们点击这个链接，我们就能看到一个加拿大 DNS 解析器（显然我的浏览器配置使用的就是这个解析器）正在请求一个 IPv4 记录和一个 IPv6 记录（A 和 AAAA）。

(at this point in the demo everyone in the audience starts visiting the link and it gets a bit chaotic, it’s very funny)
(在演示过程中，所有观众都开始访问链接，场面有点混乱，非常有趣）。

So the trick here is to find ways to show people parts of what the computer is doing that are normally hidden.
因此，这里的诀窍就是想方设法向人们展示计算机正在做的那些通常被隐藏起来的部分。

Another great example of showing things that are hidden is this website called float.exposed by Bartosz Ciechanowski who makes a lot of incredible visualizations.
另一个展示隐藏事物的好例子是 Bartosz Ciechanowski 制作的名为 float.exposed 的网站，他制作了很多令人难以置信的可视化作品。

So if you look at this 32-bit floating point number and click the "up" button on the significand, it'll show you the next floating point number, which is 2 more. And then as you make the number bigger and bigger (by increasing the exponent), you can see that the floating point numbers get further and further apart.
因此，如果你查看这个 32 位浮点数，并点击符号上的 "向上 "按钮，它就会显示下一个浮点数，也就是多 2 位数。然后，随着数字越来越大（通过增加指数），你会发现浮点数之间的距离越来越远。

Anyway, this is not a talk about floating point. I could do an entire talk about this site and how we can use it to see how floating point works, but that's not this talk.
总之，这不是一场关于浮点运算的演讲。我可以用整篇文章来介绍这个网站，以及我们如何利用它来了解浮点运算的原理，但这不是我要说的。

Another thing that makes DNS confusing is that it's a giant distributed system -- maybe you're confused because there are 5 million computers involved (really, more!). Most of which you have no control over, and some are doing not what they're supposed to do.
另一个让 DNS 感到困惑的原因是，它是一个巨大的分布式系统 -- 也许你感到困惑是因为有 500 万台计算机参与其中（真的，更多！）。其中大部分电脑你都无法控制，有些电脑所做的并不是它们应该做的。

So that's another trick for understanding why things are hard, check to see if there are actually 5 million computers involved.
所以，这也是理解事情为何困难的另一个窍门，那就是检查一下是否真的有 500 万台电脑参与其中。

So what else is hard about DNS?
那么 DNS 还有哪些难点呢？

We've talked about how most of the system is hidden from you, and about how it's a big distributed system.
我们已经说过系统的大部分功能都是隐藏的，也说过这是一个庞大的分布式系统。

One problem I’ve run into is that the tools are confusing.
我遇到的一个问题是工具很混乱。

One of the hidden things I talked about was: the resolver has cached data, right? And you might be curious about whether a certain domain name is cached or not by your resolver right now.
我谈到的其中一个隐藏问题是：解析器有缓存数据，对吗？你可能会好奇，你的解析器现在是否缓存了某个域名。

Just to understand what's happening: am I getting this result because it was cached? What's the deal?
只是想弄明白发生了什么：我得到这个结果是因为它被缓存了吗？这是怎么回事？

I said this was hidden, but there are a couple of ways to query a resolver to see what it has cached, and I want to show you one of them.
我说过这是隐藏的，但有几种方法可以查询解析器，看看它缓存了什么，我想向你展示其中一种。

The tool I usually use for making DNS queries is called dig, and it has a flag called +norecurse. You can use it to query a resolver and ask it to only return results it already has cached.
我通常使用的 DNS 查询工具名为 dig ，它有一个名为 +norecurse 的标志。你可以用它来查询解析器，并要求它只返回已经缓存的结果。

With dig +norecurse jvns.ca, I'm kind of asking -- how popular is my website? Is it popular enough that someone has visited it in the last 5 minutes? Because my records are not cached for that long, only for 5 minutes.
对于 dig +norecurse jvns.ca ，我想问的是 -- 我的网站有多受欢迎？在过去 5 分钟内是否有人访问过？因为我的记录不会缓存那么久，只有 5 分钟。

But when I look at this response, I feel like "please! What is all this?"
但当我看到这个回复时，我觉得 "拜托！这都是些什么啊？"

And when I show newcomers this output, they often respond by saying "wow, that's complicated, this DNS thing must be really complicated". But really this is just not a great output format, I think someone just made some relatively arbitrary choices about how to print this stuff out in the 90s and it's stayed that way ever since.
当我向新人展示这种输出格式时，他们往往会说："哇，好复杂，DNS 一定很复杂"。但实际上，这种输出格式并不好，我认为在上世纪 90 年代，有人对如何打印这种东西做了一些相对武断的选择，之后就一直这样了。

So a bad output format can mislead newcomers into thinking that something is more complicated than it actually is.
因此，糟糕的输出格式会误导新手，让他们以为某些东西比实际情况更复杂。

What can we do about confusing output like this?
我们能为这样的混乱输出做些什么？

One of my favorite tricks, I call eraser eyes.
我最喜欢的技巧之一，叫做 "橡皮擦眼睛"。

Because when I look at that output, I'm not looking at all of it, I'm just looking at a few things. My eyes are ignoring the rest of it.
因为当我看这些输出时，我并不是在看全部，我只是在看一些东西。我的眼睛忽略了其他部分。

When I look at the output, this is what I see: it says SERVFAIL. That's the DNS response code.
当我查看输出结果时，我看到的是：上面写着 SERVFAIL 。这是 DNS 响应代码。

Which as I understand it is a very unintuitive way of it saying, "I do not have that in my cache". So nobody has asked that resolver about my domain name in the last 5 minutes, which isn't very surprising.
据我所知，这是一种非常不直观的说法："我的缓存中没有这个域名"。因此，在过去 5 分钟内，没有人向解析器询问过我的域名，这并不奇怪。

I've learned so much from people doing a little demo of a tool, and showing how they use it and which parts of the output or UI they pay attention to, and which parts they ignore.
我从人们的工具演示中学到了很多东西，他们展示了如何使用工具，以及他们关注输出或用户界面的哪些部分，忽略了哪些部分。

Becuase usually we ignore most of what's on our screens!
因为我们通常会忽略屏幕上的大部分内容！

I really love to use dig even though it's a little hairy because it has a lot of features (I don't know of another DNS debugging that supports this +norecurse trick), it's everywhere, and it hasn't changed in a long time. And I know if I learn its weird output format once I can know that forever. Stability is really valuable to me.
我真的很喜欢使用 dig ，尽管它有点毛毛躁躁，因为它有很多功能（我不知道还有哪个 DNS 调试支持 +norecurse 这一招），它无处不在，而且很久没有改变过了。而且我知道，如果我学会了它奇怪的输出格式，我就能永远记住它了。稳定性对我来说真的很重要。

So we’ve talked about these four technologies. Let’s talk a little more about how we can make things easier for each other.
因此，我们已经谈到了这四种技术。让我们再来谈谈如何让彼此的工作变得更轻松。

What can we do to move folks from “I really don’t get it” to “okay, I can mostly deal with this, at least 90% of the time, it’s fine”? For bash or HTTP or DNS or anything else.
怎样才能让人们从 "我真的不明白 "转变为 "好吧，我基本上能应付，至少 90% 的时间没问题"？对于 bash、HTTP、DNS 或其他任何东西。

We've talked about some tricks I use to bring people over, like:
我们讨论过我用来吸引人的一些技巧，比如：

• sharing useful tools  分享有用的工具
• sharing references 共享参考资料
• telling a chronological story of what happens on your computer
  按时间顺序讲述计算机上发生的故事
• turning a big list into a small list of the things you actually use
  将大清单变成你实际使用的小清单
• showing the hidden things
  隐约可见
• demoing a confusing tool and telling folks which parts I pay attention to
  演示令人困惑的工具，并告诉人们我注意哪些部分

When I practiced this talk, I got some feedback from people saying “julia! I don’t do those things! I don’t have a blog, and I’m not going to start one!”
当我练习这个演讲时，有人对我说："朱莉娅！我不做这些事！我没有博客，也不会开博客！"

And it's true that most people are probably not going to start programming blogs.
的确，大多数人可能都不会开始写博客编程。

But I really don't think you need to have a public presence on the internet to tell the people around you a little bit about how you use computers and how you understand them.
但我真的不认为，你需要在互联网上公开向周围的人介绍一下你是如何使用电脑以及如何理解电脑的。

My experience is that a lot of people (who do not have blogs!) have helped me understand how computers work and have shared little pieces of their experience with computers with me.
我的经验是，很多人（他们没有博客！）帮助我了解了计算机的工作原理，并与我分享了他们使用计算机的小经验。

I've learned a lot from my friends and my coworkers and honestly a lot of random strangers on the Internet too. I'm pretty sure some of you here today have helped me over the years, maybe on Twitter or Mastodon.
我从我的朋友和同事身上学到了很多东西，老实说，也从互联网上的很多陌生人身上学到了很多东西。我敢肯定，今天在座的有些人多年来帮助过我，也许是在 Twitter 上，也许是在 Mastodon 上。

So I want to talk about some archetypes of helpful people
因此，我想谈谈乐于助人者的一些原型

One kind of person who has really helped me is the grumpy old-timer. I'll say "this is so cool". And they'll reply yes, however, let me tell you some stories of how this has gone wrong in my life.
有一种人对我的帮助很大，那就是脾气暴躁的老前辈。我会说 "这太酷了"。他们会回答 "是的"，不过，让我告诉你一些我生活中如何出错的故事吧。

And those stories have sometimes helped spare me some suffering.
这些故事有时会让我免受一些痛苦。

We have the loud newbie, who asks questions like "wait, how does that work?" And then everyone else feels relieved -- "oh, thank god. It's not just me."
我们有一个大嗓门的新手，他会问 "等等，这怎么用？"之类的问题。然后其他人都松了口气 -- "哦，谢天谢地，不只是我"。不光是我

I think it's especially valuable when the person who takes the "loud newbie" role is actually a pretty senior developer. Because when you're more secure in your position, it's easier to put yourself out there and say "uh, I don't get this" because nobody is going to judge you for that and think you're incompetent.
我认为，如果扮演 "大嗓门新手 "角色的人实际上是一名资深开发人员，那么这一点就尤为重要。因为当你的地位比较稳固时，你就更容易站出来说 "呃，我不懂这个"，因为没有人会因此对你评头论足，认为你无能。

And then other people who feel more like they might be judged for not knowing something can ride along on your coattails.
然后，其他觉得自己可能会因为不知道某些事情而受到评判的人就可以搭上你的顺风车。

Then we have the bug chronicler. Who decides "ok, that bug. This can never happen again".
然后我们就有了虫子记录员。他决定 "好吧，这个 bug。这种情况再也不会发生了"。

"I'm gonna make sure we understand what happened. Because I want this to end now."
"我要确保我们了解发生了什么因为我想现在就结束这一切"

We have the tool builder, whose attitude is more like “I see people struggling with something, and I don’t feel like explaining it. But I can write code to just make it easier permanently for everyone.”
我们有工具构建者，他们的态度更像是 "我看到人们在为某些事情而挣扎，我不想解释它。但我可以编写代码，让每个人都永久地轻松起来"。

There’s this “today I learned” person who’s into sharing cool new tools they learned about, a bug that they ran into, or a great new-to-them library feature.
有些人喜欢 "今天我学到了什么"，分享他们学到的很酷的新工具、遇到的 bug 或图书馆的新功能。

There’s the person who has read the entire Internet and has 700 tabs open. If you want to know where to find something, there’s a good chance they already have it open in their browser.
有些人已经阅读了整个互联网，并打开了 700 个标签。如果你想知道在哪里可以找到某样东西，他们很有可能已经在浏览器中打开了。

We have the person who is just willing to answer questions! “Yeah, I can tell you how that works!”
我们有的人只愿意回答问题！"是啊，我可以告诉你怎么用！"

And at the end of all this, sometimes you have someone who likes to write some things down so that other people can read it and can find it later.
最后，有时有人会喜欢把一些事情写下来，这样其他人就能读到，以后也能找到。

But all of us have different roles and we need to work together. I’m into writing but a lof of the stuff I’ve written about, I only know about because someone told me about it or explained it to me.
但我们每个人都扮演着不同的角色，我们需要共同努力。我喜欢写作，但我写的很多东西都是别人告诉我或解释给我听我才知道的。

To end: the one thing I would like to convince you of is: if you’re struggling with something that feels basic, it’s not just you! You’re not alone. We’re all struggling with a lot of these things that feel like they should be “basic”.
最后：我想让你们相信的一件事是：如果你正在为一些感觉很基本的事情而挣扎，那不仅仅是你一个人的问题！你并不孤单。我们都在为很多感觉应该是 "基本 "的事情而挣扎。

And we’re struggling with these things for a lot of the same reasons as each other.
我们在这些事情上挣扎的原因很多都是一样的。

And much like when debugging a computer program, when you have a bug, you want to understand why the bug is happening if you're gonna fix it.
就像调试计算机程序一样，当你发现一个错误时，如果要修复它，就必须了解错误发生的原因。

If we're all struggling with the same things together for the same reasons, if we can figure out what those reasons are, we can do a better job of fixing them.
如果我们都因为同样的原因而共同面对同样的问题，如果我们能找出这些原因，我们就能更好地解决问题。

Some of the reasons we’ve talked about were:
我们谈到的一些原因是

• a giant pile of trivia and gotchas.
  一大堆琐事和难题。
• or maybe there's 20 million lines of code somewhere.
  或者在某个地方有 2000 万行代码。
• Maybe a big part of the system is being hidden from you.
  也许系统的很大一部分都被你隐藏起来了。
• Maybe the tool's output is extremely confusing and no UI designer has ever worked on improving it
  也许该工具的输出结果极其混乱，而且用户界面设计师从未对其进行过改进

And there are a lot more reasons.
原因还有很多。

I don’t have all the answers for why things are hard. For example I don’t really understand why Git is hard, that’s something I’ve been thinking about recently.
我不知道为什么事情很难做。例如，我不太明白 Git 为什么很难，这是我最近一直在思考的问题。

But that’s something I’m excited to keep working on and keep trying to figure out.
不过，我很高兴能继续努力，不断摸索。

And that's all I have for you. Thank you.
我就说这么多。谢谢

I brought some zines to the conference, if you come to the signing later on you can get one.
我给大会带来了一些杂志，如果你来参加稍后的签售会，就能得到一本。