谷歌第一个开源编程语言

by Anthony Ng

由Anthony Ng

我的第一个开源冒险 (My First Open Source Adventure)

✨✨灵感✨✨ (✨✨ Inspiration ✨✨)

The idea of open source has always resonated with me. What’s not to like about people volunteering their time and knowledge for the common good?

开源的想法一直引起我的共鸣。 人们为了共同的利益而自愿奉献自己的时间和知识，那会是什么呢？

So after reading Shubheksha’s article Hey newbie open source contributors: please blog more, I decided to throw my hat into the ring.

因此，在阅读了Shubheksha的文章嘿，新手开源贡献者之后：请多写博客 ，我决定投入很多精力 。

I’ve been told that working on open source projects is one of the best ways to learn.

有人告诉我，从事开源项目是最好的学习方法之一。

• You get to see code written by more experienced developers.您会看到由更有经验的开发人员编写的代码。
• You get to work with technology that you wouldn’t have otherwise used on your own hobby projects.您将开始使用自己的业余项目无法使用的技术。

Contributing to open source is a way of expressing your altruistic nature. I imagine a Robin Hood figure armed with a MacBook (which you can barely distinguish under its 20 stickers), courageously battling cumbersome closed-source enterprise software.

为开源做贡献是表达您无私的本性的一种方式。 我想象一个罗宾汉(Robin Hood)身着MacBook(在20个贴纸下几乎看不到)的形象，勇敢地与繁琐的封闭源代码企业软件作斗争。

I wanted to be an open source Robin Hood.

我想成为一个开源的罗宾汉。

☠☠恐惧☠☠ (☠☠ Fears ☠☠)

As I peered into my monitor, the first of many fears entered my mind. What if I’m overwhelmed by the complexity of these open source projects?

当我凝视我的显示器时，许多恐惧中的第一个进入了我的脑海。 如果我对这些开源项目的复杂性不知所措怎么办？

Staring down a repository that has 2,000 commits was quite daunting — especially when my hobby projects topped out at 40 commits.

盯着一个拥有2,000次提交的存储库非常艰巨-特别是当我的业余爱好项目达到40次提交时。

As I started navigating through the forest of files with cryptic names that I’ve never heard of (.snyk, .varci.yml, pm2Start.js), thoughts of imposter syndrome quickly crept in. I asked myself, “Am I actually qualified to touch this code?”

当我开始浏览从未听说过的带有神秘名字的文件(.snyk，.varci.yml，pm2Start.js)时，冒名顶替综合症的念头Swift泛滥。我问自己：“我真的合格了吗？触摸此代码？”

I’d heard some horror stories about harsh communities. What would happen when I got to a point where I need some guidance and had to actually…talk to a person?

我听到了一些有关恶劣社区的恐怖故事。 当我到达需要指导的地方并且不得不与人交谈时会发生什么？

Dread suffocated me as I thought about having my first conversation with an open source maintainer. In my head, their responses ranged from “lol are you serious?” to “maybe web development isn’t for you.”

当我想到与开源维护者的第一次对话时，Dread令我窒息。 在我的脑海中，他们的回答范围是“你是认真的吗？” “也许Web开发不适合您。”

But I took comfort in the fact that, like an internet troll, I could hide myself (and my shame) behind my computer.

但是我感到很安慰，因为就像互联网巨魔一样，我可以将自己(和我的耻辱)隐藏在计算机后面。

I also feared that my pull request wouldn’t get merged. It was possible that my work was so poor that other maintainers won’t bother to steer me in the right direction. Would it be worth devoting hours — or even days — of my time toward code that might not even get used?

我还担心我的请求请求不会被合并。 我的工作可能太差了，以至于其他维护人员不会费心将我引向正确的方向。 花费数小时甚至数天的时间来编写甚至无法使用的代码是否值得？

Despite these fears, I decided to embark on my open source adventure.

尽管有这些担心，我还是决定开始我的开源冒险。

?? 寻找一个项目 (?? Finding a project ??)

The first step was finding an Open Source Project to work on. Shubheksha’s article How to find your first open source bug to fix recommended looking at Up For Grabs for project candidates. After quickly scanning through the list of JavaScript projects, I didn’t find any that caught my eye.

第一步是找到一个可以进行的开源项目。 Shubheksha的文章如何找到您的第一个开放源代码错误以进行修复，建议针对项目候选人查看Up For Grabs 。 在快速浏览JavaScript项目列表之后，我没有发现任何吸引我眼球的东西。

I wanted to find a project that I personally used and believed in. The problem was most of those projects were so mature that they were too advanced for me to follow along. For example, I love React, but I didn’t have any idea how to fix “unexpected interleaving of subtree/parent lifecycle methods.”

我想找到一个我个人使用并相信的项目。问题是这些项目中的大多数都很成熟，以至于它们太先进了，我无法跟进。 例如，我喜欢React，但是我不知道如何解决“子树/父生命周期方法的意外交织”。

I was sure that there were projects out there where I could make a significant dent, but they were still unknown to me.

我确定那里有一些项目可以使我产生重大影响，但我仍然不知道这些项目。

Then I remembered that Free Code Camp is open source. It passed my test as a project that I use and believe in. I’ve gone through hours of their curriculum, and love how they help new developers and nonprofits at the same time. I also recommend Free Code Camp to anyone who mentioned wanting to learn web development.

然后我想起了Free Code Camp是开源的。 它作为一个我使用并坚信的项目通过了我的测试。我经历了他们数小时的课程，并且热爱他们如何同时帮助新的开发商和公益组织。 我还向所有想学习Web开发的人推荐免费代码营。

So after scanning through their list of open issues on GitHub, I chose Free Code Camp as my first Open Source Project.

因此，在浏览了他们在GitHub上的未解决问题列表之后，我选择了Free Code Camp作为我的第一个开源项目。

?? 寻找错误？ (?? Finding a bug ??)

The next step was finding an issue to work on. In theory, this should have been the easiest and quickest thing to do.

下一步是找到需要解决的问题。 从理论上讲，这应该是最简单，最快的事情。

But, like watching a movie on Netflix, sometimes you spend more time picking something to watch than actually watching it.

但是，就像在Netflix上观看电影一样，有时您花费更多的时间挑选要观看的东西而不是实际观看。

With over 300 open issues, I decided to filter them by labels. I found one labeled “first-timers-only” which sounded friendly enough. But this issue had more than 80 comments. I wasn’t about to touch that.

对于300多个未解决的问题，我决定按标签过滤它们。 我发现一个标签为“仅限初学者”的听起来足够友好。 但是这个问题有80多条评论。 我不想碰那个。

I didn’t see any issues that I could jump right into and start working on, so I continued my search.

我没有发现任何可以立即解决并开始解决的问题，因此我继续进行搜索。

I found another label called “help wanted” and scanned for issues that no one had commented on yet, but nothing jumped out at me.

我找到了另一个名为“需要帮助”的标签，并扫描了尚未有人发表评论的问题，但没有发现我。

I decided instead to watch the repo for new issues that no one had tackled yet. After about 15 minutes, I saw that most of the new issues were from campers who were stuck on challenges. These issues weren’t actually bugs that I could fix.

相反，我决定观看回购中是否有尚未解决的新问题。 大约15分钟后，我看到大多数新问题出自那些坚持挑战的露营者。 这些问题实际上并不是我可以解决的错误。

And then issue #10989 came into my life. It was related to a overly-rigid regular expressions test on one of the coding challenges.

然后， 问题＃10989进入了我的生活。 它与对其中一种编码挑战的过严格的正则表达式测试有关。

I thought to myself, “I know a little about regex.”

我对自己说：“我对正则表达式有所了解。”

Then a maintainer commented that this was a valid issue and added a “help wanted” label to it. My heart started pounding as I reread the issue 3 more times to make sure I didn’t miss anything.

然后，维护人员评论说这是一个有效的问题，并在其中添加了“需要帮助”标签。 当我再读3次以确保没有任何遗漏时，我的心开始跳动。

Then I thought to myself, “I can do this!”

然后我对自己想：“我能做到！”

I commented on the issue and shyly asked if I could work on it. My knees were weak and my arms were heavy. My palms were sweating as I waited for a response. I felt as nervous as if I had just texted a woman asking her on a date.

我对此问题发表了评论，并害羞地问我是否可以解决这个问题。 我的膝盖无力，手臂沉重。 等待响应时，我的手掌出汗。 我感到紧张，就好像我刚给一个女人发短信问她约会时一样。

And finally, someone responded with, “you can work on that.”

最后，有人回应说：“您可以继续努力。”

Time to get to work.

该上班了。

??? 入门 ？？？ (??? Getting started ???)

I started by looking through the README.md in the repository. Thankfully, Free Code Camp has very detailed instructions on how to contribute and create pull requests. They also have a Gitter channel just for contributors.

我从浏览存储库中的README.md开始。 幸运的是，Free Code Camp提供了有关如何贡献和创建请求请求的非常详细的说明。 他们还有一个供贡献者使用的Gitter频道。

I forked the repository and got started.

我分叉存储库并开始使用。

?? 绊倒?? (?? Stumbling ??)

I knew that getting my environment set up would be tough. My mentor told me that it took him a week to get all the right programs installed before he could start contributing at his first job.

我知道设置环境会很困难。 我的导师告诉我，他花了一个星期的时间来安装所有正确的程序，然后他才可以开始从事他的第一份工作。

It’s difficult because you have to read these cryptic error messages in your terminal when something doesn’t install or run correctly. And sure enough, it wasn’t long before I ran into an issue.

这很困难，因为当某些东西无法正确安装或运行时，您必须在终端中阅读这些隐秘的错误消息。 可以肯定的是，不久之后我遇到了一个问题。

When I ran “gulp” to get started, there was an error inside of the gulpfile. It highlighted a line of code that used the ES6 arrow syntax and said that it didn’t recognize it. I looked through the rest of the file and saw no other use of the ES6 arrow syntax. Could I have forgotten a step in the build process?

当我运行“ gulp”开始学习时，gulpfile内部出现错误。 它突出显示了使用ES6箭头语法的一行代码，并说它无法识别。 我浏览了文件的其余部分，没有看到ES6箭头语法的其他用法。 我可以忘记构建过程中的步骤吗？

I googled around for a solution and got nothing helpful. So I decided to hack it. I turned the ES6 arrow into a regular function declaration and see what happened. The “gulp” command didn’t complain anymore, and set up a localhost.

我到处搜寻解决方案，但没有任何帮助。 所以我决定破解它。 我将ES6箭头变成了常规函数声明，然后看看发生了什么。 “ gulp”命令不再抱怨，并设置了本地主机。

High off of this success, it didn’t take long before I ran into another road block. I went to my localhost and was greeted with the Free Code Camp home page, except that it wasn’t functional. Clicking on the “map” link that normally displays all challenges did nothing. There were a number of errors in the console, most noticeably a missing “bundle.js” file.

这次成功很大，不久之后我遇到了另一个障碍。 我去了我的本地主机，并受到了Free Code Camp主页的欢迎，除了它没有功能。 单击通常显示所有挑战的“地图”链接没有任何作用。 控制台中存在许多错误，最明显的是缺少“ bundle.js”文件。

I kicked myself for missing a step somewhere, and decided to start from scratch. I deleted my local copy of the repo and reinstalled everything, making sure to be extra vigilant with each keystroke. I meet with the same errors and decide it’s time to use the Gitter channel.

我因错过某处步骤而踢自己，并决定从头开始。 我删除了本地的回购副本，并重新安装了所有内容，确保每次敲击时都要格外警惕。 我遇到同样的错误，并决定是时候使用Gitter频道了。

When I first logged into the Gitter channel, I saw a lot of messages talking about new updates to Free Code Camp. To my right, I was greeted by a summary of recent activity on this channel, which included the banning of four people. Were these people guilty of not getting their gulp files to work? Did they nonchalantly ask where their missing bundle.js file was?

当我第一次登录Gitter频道时，我看到很多消息都在谈论Free Code Camp的新更新。 在我的右边，我对该频道最近的活动进行了总结，其中包括禁止四个人。 这些人是否因为没有使他们的gulp文件正常工作而感到内?？ 他们是否坚定地询问丢失的bundle.js文件在哪里？

I decided to read through the contribution guide again in case I missed something obvious. I’d already read through it so many times that I could practically recite it. I didn’t find anything new that would help me, so I conjured up the strength to finally ask the Gitter channel about my ES6 syntax issue.

我决定再次通读贡献指南，以防万一我错过了明显的事情。 我已经读了很多遍，几乎可以背诵它。 我没有发现任何对我有帮助的新东西，所以我想起了最终向Gitter频道询问我的ES6语法问题的力量。

Someone responded right away, but I quickly realized they weren’t talking to me.

有人立即做出了回应，但我很快意识到他们没有在跟我说话。

I waited and waited until salvation came. A maintainer named Dylan told me that I had to update my Node and npm. I looked again at the contribution guide, and realized that it clearly states the version I should be using. How did I overlook this?!

我等着救赎到来。 一个名为Dylan的维护者告诉我，我必须更新Node和npm。 我再次查看了贡献指南，并意识到它明确指出了我应该使用的版本。 我怎么忽略了这个？

I thanked Dylan for his act of kindness and I quietly thank Gitter for not banning me.

我感谢迪伦(Dylan)的友善举止，并默默地感谢吉特(Gitter)没有禁止我。

I promptly installed the latest version of Node and npm. Things are looking brighter already.

我及时安装了最新版本的Node和npm。 事情已经看起来光明了。

I decided to delete everything and start from scratch again. It was my third time at this point, and setting this project up had become a familiar dance. I also pulled some new code that has been committed since the day before, which fixed some of the errors I was seeing.

我决定删除所有内容，然后从头开始。 这是我第三次参加这个项目，建立这个项目已成为一种熟悉的舞蹈。 我还拉出了自前一天以来提交的一些新代码，这些代码修复了我所看到的一些错误。

I run into the same error with the missing “bundle.js” file and I asked in the Gitter channel about this. Someone responded that the “gulp” command should have created it. I created the “bundle.js” by running the “webpack” command myself, and finally the environment looked like it was working. I could finally start working on the actual issue!

我因缺少“ bundle.js”文件而遇到相同的错误，并在Gitter频道中询问了此问题。 有人回答说，“ gulp”命令应该已经创建了它。 我自己运行“ webpack”命令创建了“ bundle.js”，最终环境看起来像在运行。 我终于可以开始处理实际问题了！

The actual fix took a quarter of the time that setting up my project took. I wrote a regex that checked for the presence of an element. The tricky part was to turn my regex into a string, then remember to use backslashes to escape characters as needed. I updated one line of code and ran my tests, which passed.

实际的修复花费了我设置项目所需时间的四分之一。 我写了一个正则表达式来检查元素的存在。 棘手的部分是将我的正则表达式转换为字符串，然后记住根据需要使用反斜杠转义字符。 我更新了一行代码并运行了测试，并通过了测试。

I read through the documentation for pull request instructions. Free Code Camp has an awesome pre-populated checklist when you submit a pull request.

我通读了有关拉取请求说明的文档。 当您提交请求请求时，Free Code Camp会有一个很棒的预填充清单。

I took a final breath and sent off my pull request. I felt like a parent sending their child off to school. There was nothing else I could do except wait.

我屏住了呼吸，发出了请求请求。 我感觉就像是父母送孩子上学。 除了等待，我无能为力。

?? 合并请求合并！ ?? (?? Pull Request Merged! ??)

The next day, I got an email about the status of my pull request. Someone commented “LGTM.”

第二天，我收到了有关我的请求请求状态的电子邮件。 有人评论“ LGTM”。

I did a quick Google search and discovered that this stands for “Looks good to me.” Then I felt a big sense of relief. They had merged my pull request!

我在Google上进行了快速搜索，发现它代表“对我来说很好”。 然后，我感到很宽慰。 他们合并了我的请求请求！

My first step into open source had been a success!

我迈入开源的第一步取得了成功！

?? 我学到的是 ？？ (?? What I learned ??)

I did learn some technical things by working on this issue. I got more experience working with regex.

通过解决此问题，我确实学到了一些技术知识。 我有更多使用正则表达式的经验。

I also learned about using backslashes to escape certain characters in strings. Before this, I’d only used backslashes to escape quotation marks.

我还学习了如何使用反斜杠来转义字符串中的某些字符。 在此之前，我仅使用反斜杠来转义引号。

The other benefit is that I got a lot more comfortable using GitHub.

另一个好处是我对使用GitHub更加满意。

?? 新开源贡献者的话 (?? Words to new Open Source contributors ??)

This was an amazing experience for me, and I recommend other new developers give it a shot. Here’s my advice to those interested in contributing.

对我来说，这是一次了不起的经历，我建议其他新开发者尝试一下。 这是我对有兴趣贡献者的建议。

提示1：努力工作并持之以恒 (Tip 1: Work hard and persevere)

I would say 60% of the time when you’re working, everything runs without issues. But it’s that other 40% when everything breaks that will define who you are as a developer.

我想说60％的时间，当您在工作时，一切都会正常运行。 但这一切发生时，只有另外40％的人会确定您是开发人员的身份。

Embrace these obstacles and fight through them.

拥抱并克服这些障碍。

I learned more from fixing my bugs than I would have if everything had run smoothly.

通过修复错误，我学到的东西比一切运行顺利时要多。

Change your mindset to welcome mistakes. View them as lessons.

改变思维方式，迎接错误。 将它们视为课程。

提示2：尽可能多地交流细节。 (Tip 2: Communicate as many details as you can.)

This is especially important when you’re asking questions over an asynchronous mode of communication (like Gitter or email).

当您通过异步通信模式(例如Gitter或电子邮件)提问时，这一点尤其重要。

Imagine you’re using an API to request information about the weather in your city. You could do this: 1. You ask the API for the weather 2. The API responds back asking for a location 3. You respond “New York” 4. The API asks if you want it in celsius, Fahrenheit or kelvin 5. You respond “Fahrenheit” 6. The API responds back with “72 degrees Fahrenheit in New York”

假设您正在使用API​​来请求有关城市天气的信息。 您可以执行以下操作：1.您向API询问天气情况2. API回复要求输入位置3.您回答“纽约” 4. API询问您是否要使用摄氏，华氏或开尔文5.您回复“华氏温度” 6. API回复“纽约华氏72度”

Or you could do this: 1. You ask the API for the weather in New York in Fahrenheit. 2. The API responds back with “72 degrees Fahrenheit in New York”

或者，您可以这样做：1.您向API查询华氏温度纽约的天气。 2. API会回复“纽约华氏72度”

It seems silly that anyone would choose the first option when working with an API, but that’s exactly what people do when they’re communicating with other people. Simple conversations get drawn out while each party waits minutes or hours for the other to respond.

所有人在使用API​​时都会选择第一个选项，这似乎很可笑，但这正是人们与他人交流时所做的。 当双方等待几分钟或几小时以使对方做出响应时，就会产生简单的对话。

提示3：不要被开源维护者吓倒。 (Tip #3: Don’t be intimidated by open source maintainers.)

They may have more experience than you do, but realize that at one point, they were in your situation, too. They’ve just survived more mistakes than you have.

他们可能比您有更多的经验，但要意识到，在某一时刻，他们也处于您的情况。 他们刚刚经历了比您更多的错误。

Just remember that all developers are on the same long road. Some of us are a few steps behind others. The important thing is to keep moving.

请记住，所有开发人员都在同一条漫长的道路上。 我们中有些人比其他人落后了几步。 重要的是要继续前进。

?? 开源维护者的话 (?? Words to Open Source maintainers ??)

The Free Code Camp community is amazing, and was super helpful when I needed it.

Free Code Camp社区非常了不起，在我需要的时候非常有帮助。

I want to thank all the maintainers who go out of their way to help out new contributors. You might think you’re doing something small when you’re telling someone to update their node and npm. What you may not realize is that you may be their lifesaver, keeping them from drowning and quitting.

我要感谢所有努力帮助新贡献者的维护者。 当您告诉某人更新其节点和npm时，您可能会认为您在做些小事情。 您可能没有意识到，您可能是他们的救星，可以防止他们淹死和退出。

Keep up the awesome work!

继续努力！

Also, be careful with the words you choose to use.

另外，请注意选择使用的单词。

I was on a trip to Japan and was looking for a restaurant to dine. I passed by a promising restaurant, but it had a sign on the window that said “No English Speaking.” Everything else was in Japanese.

我去日本旅行时，正在寻找一家餐厅用餐。 我经过一家有前途的餐厅，但是窗户上有一个标语，上面写着“不会说英语”。 其他所有内容均为日语。

How would a foreigner like me have interpreted this sign? Does it mean that nobody in there speaks English? Does it mean that I’d have to play Russian Roulette with whatever I pointed to on the menu? Does it mean they’re xenophobic and not welcoming of foreigners like me? I kept walking and never bothered to find out.

像我这样的外国人将如何解释这个标志？ 这是否意味着那里没有人会说英语？ 这是否意味着我必须按照菜单上的指示玩俄罗斯轮盘赌？ 这是否意味着他们仇外，不欢迎像我这样的外国人？ 我一直走着，从不费心去寻找。

As maintainers, sometimes you’re the first real person that new contributors communicate with. Be mindful that these contributors are in the foreign land of open source. They may be struggling to speak the language — let alone try to fix an open issue in the repository.

作为维护者，有时您是与新贡献者进行交流的第一个人。 请注意，这些贡献者位于开放源代码的外国。 他们可能很难说这种语言-更不用说尝试解决存储库中的一个未解决的问题了。

I plan on continuing my open source journey. I hope to see you around and hear your stories.

我计划继续我的开源之旅。 我希望能与您见面并听到您的故事。

翻译自: https://www.freecodecamp.org/news/my-first-open-source-adventure-82a33f89113/

谷歌第一个开源编程语言