FETalk

起始于 Javascript 而不止于 Javascript

最新文章

不要害怕 Rebase
Git 的 rebase 命令是 Git 用户害怕和迷惑的一个常见源头，特别是那些来自可能更集中的版本控制系统的用户。这很正常。Rebase 是一个不可思议又充满魔力的怪兽，一上来不管…查看全文
根号三
a month ago
0 赞0 条评论
作为一个开源软件的作者是一种什么样的感受？
原文地址：What it feels like to be an open-source maintainer原文作者：Nolan Lawson译文出自：作为一个开源软件的作者是一种什么样的感受？译者：根号三你的门外有几百…查看全文
根号三
a year ago
1 赞0 条评论
是时候来用 Slush 构建你自己的脚手架了
Slush 是什么？简单的来说，Slush 就是一个脚手架生成工具。什么？脚手架？这是什么鬼？嗯，脚手架嘛，自然是这个样子咯~什么？你问的是编程中的脚手架呀？啊，这么说吧。…查看全文
根号三
a year ago
0 赞0 条评论
一个关于 Styled Components 的五分钟介绍
原文地址：A 5-minute Intro to Styled Components原文作者：Sacha Greif译文出自：掘金翻译计划译者：根号三校对者：Tina92、lovelyCiTY文章首发于 sqrthree/sqrthree.git…查看全文
根号三
a year ago
3 赞2 条评论

{"database":{"Post":{"25168240":{"title":"一个关于 Styled Components 的五分钟介绍","author":"sqrtthree","content":"\u003Cblockquote\u003E\u003Cul\u003E\u003Cli\u003E原文地址：\u003Ca href=\"https:\u002F\u002Fmedium.freecodecamp.com\u002Fa-5-minute-intro-to-styled-components-41f40eb7cd55#.z1nrxe1zr\" data-editable=\"true\" data-title=\"A 5-minute Intro to Styled Components\" class=\"\"\u003EA 5-minute Intro to Styled Components\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E原文作者：\u003Ca href=\"https:\u002F\u002Fmedium.freecodecamp.com\u002F@sachagreif\" data-editable=\"true\" data-title=\"Sacha Greif\" class=\"\"\u003ESacha Greif\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E译文出自：\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fxitu\u002Fgold-miner\" data-editable=\"true\" data-title=\"掘金翻译计划\" class=\"\"\u003E掘金翻译计划\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E译者：\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fsqrthree\" data-editable=\"true\" data-title=\"根号三\" class=\"\"\u003E根号三\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E校对者：\u003Ca href=\"https:\u002F\u002Fgithub.com\u002FTina92\" data-editable=\"true\" data-title=\"Tina92\" class=\"\"\u003ETina92\u003C\u002Fa\u003E、\u003Ca href=\"https:\u002F\u002Fgithub.com\u002FlovelyCiTY\" data-editable=\"true\" data-title=\"lovelyCiTY\" class=\"\"\u003ElovelyCiTY\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cbr\u003E文章首发于 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fsqrthree\u002Fsqrthree.github.io\u002Fissues\u002F11\" class=\"\" data-editable=\"true\" data-title=\"sqrthree\u002Fsqrthree.github.io\"\u003Esqrthree\u002Fsqrthree.github.io\u003C\u002Fa\u003E\u003C\u002Fblockquote\u003E\u003Cp\u003ECSS 是一个很神奇的语言，你可以在 15 分钟之内就学会一些基础部分，但是如果你要找到一个好的方式来组织你的样式，将会花费数年时间。\u003C\u002Fp\u003E\u003Cp\u003E这主要是由于语言本身很奇葩。不合常规的是， CSS 是相当有限的，没有变量、循环或者函数。与此同时，它又是相当自由的，你可以随意使用元素、Class、ID 或它们的任意组合。\u003C\u002Fp\u003E\u003Ch2\u003E混乱的样式表\u003C\u002Fh2\u003E\u003Cp\u003E正如你自己所经历过的那样，CSS 通常是很混乱的。虽然有诸如 SASS 和 LESS 这样的预处理器添加了大量有用的特性，但是它们仍然不能阻止 CSS 的这种混乱状态。\u003C\u002Fp\u003E\u003Cp\u003E组织工作留给了像 \u003Ca href=\"http:\u002F\u002Fgetbem.com\u002F\" data-editable=\"true\" data-title=\"BEM\"\u003EBEM\u003C\u002Fa\u003E 这样的方法，这些方法虽然很有用但是完全是自选方案，不能在语言或工具级别强制实施。\u003C\u002Fp\u003E\u003Ch3\u003ECSS 的新浪潮\u003C\u002Fh3\u003E\u003Cp\u003E最近一两年，新一波基于 JavaScript 的工具正试图通过改变编写 CSS 的方式来从根本上解决这些问题。\u003C\u002Fp\u003E\u003Cp\u003E\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fstyled-components\u002Fstyled-components\" data-editable=\"true\" data-title=\"Styled Components\"\u003EStyled Components\u003C\u002Fa\u003E 就是那些工具库之一，因为兼顾创新和传统的优势，它很快就吸引了大量的关注。因此，如果你是 React 使用者（如果你不是的话，可以看看 \u003Ca href=\"https:\u002F\u002Fmedium.freecodecamp.com\u002Fa-study-plan-to-cure-javascript-fatigue-8ad3a54f2eb1\" data-editable=\"true\" data-title=\"我的 JavaScript 学习计划\"\u003E我的 JavaScript 学习计划\u003C\u002Fa\u003E 和我写的 \u003Ca href=\"https:\u002F\u002Fmedium.freecodecamp.com\u002Fthe-5-things-you-need-to-know-to-understand-react-a1dbd5d114a3\" data-editable=\"true\" data-title=\"React 简介\"\u003EReact 简介\u003C\u002Fa\u003E），就绝对值得看看这个新的 CSS 替代者。\u003C\u002Fp\u003E\u003Cp\u003E最近我用它 \u003Ca href=\"http:\u002F\u002Fsachagreif.com\u002F\" data-editable=\"true\" data-title=\"重新设计了我的个人网站\"\u003E重新设计了我的个人网站\u003C\u002Fa\u003E，今天我想分享下我在这个过程中所学到的一些东西。\u003C\u002Fp\u003E\u003Ch3\u003E组件，样式化\u003C\u002Fh3\u003E\u003Cp\u003E关于 Styled Components 你需要理解的最主要的事情就是其名称应该采取字面意思。你不再根据他们的 Class 或者 HTML 元素来对 HTML 元素或组件进行样式化了。\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003E&lt;h1 className=\"title\"&gt;Hello World&lt;\u002Fh1&gt;\n\nh1.title {\n  font-size: 1.5em;\n  color: purple;\n}\n\u003C\u002Fcode\u003E\u003Cp\u003E相反，你可以定义一个拥有它们自己的封装风格的 styled Components。然后你就可以在你的代码中自由的使用它们了。\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003Eimport styled from 'styled-components';\n\nconst Title = styled.h1`\n  font-size: 1.5em;\n  color: purple;\n`;\n\n&lt;Title&gt;Hello World&lt;\u002FTitle&gt;\n\u003C\u002Fcode\u003E\u003Cp\u003E这两段代码看起来有一些细微的差别，事实上两者语法是非常相似的。但是它们的关键区别在于样式现在是这些组件的一部分啦。\u003C\u002Fp\u003E\u003Cp\u003E换句话说，我们正在摆脱 CSS class 作为组件和其样式的中间步骤这种情况。\u003C\u002Fp\u003E\u003Cp\u003Estyled-components 的联合创造者 Max Stoiber 说：\u003C\u002Fp\u003E\u003Cblockquote\u003E\u003Cp\u003Estyled-components 的基本思想就是通过移除样式和组件之间的映射关系来达到最佳实践。\u003C\u002Fp\u003E\u003C\u002Fblockquote\u003E\u003Ch3\u003E减少复杂性\u003C\u002Fh3\u003E\u003Cp\u003E这首先是反直觉的，因为使用 CSS 而不是直接定义 HTML 元素的关键点（还记得 &lt;font&gt; 标签吗？）是引入 class 这个中间层来解耦样式和标签。\u003C\u002Fp\u003E\u003Cp\u003E但是这层解耦也创造了很多复杂性。有这样一个的观点：相比于 CSS，诸如 Javascript 这类『真正』的编程语言具备了更好的处理这种复杂性的能力。\u003C\u002Fp\u003E\u003Ch3\u003E类（Class）上的 Props\u003C\u002Fh3\u003E\u003Cp\u003E为了遵循 『无类(no-class)』的理念，当涉及到自定义一个组件的行为时，styled-components 使用了类上的 props（props over classes）。所以呢，代码不是这样的：\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003E&lt;h1 className=\"title primary\"&gt;Hello World&lt;\u002Fh1&gt; \u002F\u002F will be blue\n\nh1.title{\n  font-size: 1.5em;\n  color: purple;\n\n  &amp;.primary{\n    color: blue;\n  }\n}\n\u003C\u002Fcode\u003E\u003Cp\u003E你需要这样写：\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003Econst Title = styled.h1`\n  font-size: 1.5em;\n  color: ${props =&gt; props.primary ? 'blue' : 'purple'};\n`;\n\n&lt;Title primary&gt;Hello World&lt;\u002FTitle&gt; \u002F\u002F will be blue\n\u003C\u002Fcode\u003E\u003Cp\u003E正如你所看到的那样，styled-components 通过将所有的 CSS 和 HTML 之间的相关实现细节（从组件中）分离出来使你的 React 组件更干净。\u003C\u002Fp\u003E\u003Cp\u003E也就是说，styled-components 的 CSS 仍然还是 CSS。所以像下面这样的代码也是完全有效的（尽管略微不常用）。\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003Econst Title = styled.h1`\n  font-size: 1.5em;\n  color: purple;\n\n  &amp;.primary{\n    color: blue;\n  }\n`;\n\n&lt;Title className=\"primary\"&gt;Hello World&lt;\u002FTitle&gt; \u002F\u002F will be blue\n\u003C\u002Fcode\u003E\u003Cp\u003E这是让 styled-components 很容易就被接受的一个特性：当存在疑惑时，你总是可以倒退回你所熟悉的领域。\u003C\u002Fp\u003E\u003Ch3\u003E警告\u003C\u002Fh3\u003E\u003Cp\u003E需要提到的很重要的一点是 styled-components 仍然是一个很年轻的项目。有一些特性到目前为止还没有完全支持。例如，如果你想 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fstyled-components\u002Fstyled-components\u002Fissues\u002F142\" data-editable=\"true\" data-title=\"从父组件中样式化一个子组件\"\u003E从父组件中样式化一个子组件\u003C\u002Fa\u003E 时，目前你仍不得不依靠 CSS class 来实现（至少要持续到 styled-components 版本 2 发布）。\u003C\u002Fp\u003E\u003Cp\u003E目前也有一个非官方的方法来实现 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fstyled-components\u002Fstyled-components\u002Fissues\u002F124\" data-editable=\"true\" data-title=\"服务端预渲染你的 CSS\"\u003E服务端预渲染你的 CSS\u003C\u002Fa\u003E，虽然它是通过手动注入样式来实现的。\u003C\u002Fp\u003E\u003Cp\u003E事实上，styled-components 生成它自己的随机 class 名会使你很难通过浏览器的开发工具来确定你的样式最初是在哪里定义的。\u003C\u002Fp\u003E\u003Cp\u003E但是鼓舞人心的是，styled-components 核心团队已经意识到了这些问题，并且努力地一个又一个的攻克它们。版本 2 很快就要来啦，我真的很期待它呢。\u003C\u002Fp\u003E\u003Ch3\u003E了解更多一点吧\u003C\u002Fh3\u003E\u003Cp\u003E我这篇文章的目的不是向你详细解释 styled-components 是如何生效的，更多的是给你一个小瞥。所以你可以自己决定是否值得一试。\u003C\u002Fp\u003E\u003Cp\u003E如果我的文章让你感到好奇的话，这里有一些链接你可以了解更多关于 styled-components 的知识。\u003C\u002Fp\u003E\u003Cul\u003E\u003Cli\u003EMax Stoiber 最近给 \u003Ca href=\"https:\u002F\u002Fwww.smashingmagazine.com\u002F2017\u002F01\u002Fstyled-components-enforcing-best-practices-component-based-systems\u002F\" data-editable=\"true\" data-title=\"Smashing Magazine\"\u003ESmashing Magazine\u003C\u002Fa\u003E 写了一篇文章有关创建 styled-components 的原因的文章。\u003C\u002Fli\u003E\u003Cli\u003E\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fstyled-components\u002Fstyled-components\" data-editable=\"true\" data-title=\"styled-components repo\"\u003Estyled-components repo\u003C\u002Fa\u003E 它自己就有一个很丰富的文档.\u003C\u002Fli\u003E\u003Cli\u003E\u003Ca href=\"https:\u002F\u002Fmedium.com\u002F@jamiedixon\u002Fstyled-components-production-patterns-c22e24b1d896#.tfxr5bws2\" data-editable=\"true\" data-title=\"Jamie Dixon 写的这篇文章\" class=\"\"\u003EJamie Dixon 写的这篇文章\u003C\u002Fa\u003E 讲述了切换到 styled-components 的几个好处.\u003C\u002Fli\u003E\u003Cli\u003E如果你想了解更多关于这个库实际上是如何实现的，可以阅读 Max 的 \u003Ca href=\"http:\u002F\u002Fmxstbr.blog\u002F2016\u002F11\u002Fstyled-components-magic-explained\u002F\" data-editable=\"true\" data-title=\"这篇文章\"\u003E这篇文章\u003C\u002Fa\u003E。\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003Cp\u003E如果你想更进一步，也可以了解下 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fthreepointone\u002Fglamor\" data-editable=\"true\" data-title=\"Glamor\"\u003EGlamor\u003C\u002Fa\u003E —— 一个完全不同的 CSS 新浪潮。\u003C\u002Fp\u003E","updated":new Date("2017-02-09T15:49:59.000Z"),"canComment":false,"commentPermission":"anyone","commentCount":2,"likeCount":3,"state":"published","isLiked":false,"slug":"25168240","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"2017-02-09T23:49:59+08:00","links":{"comments":"\u002Fapi\u002Fposts\u002F25168240\u002Fcomments"},"url":"\u002Fp\u002F25168240","titleImage":"https:\u002F\u002Fpic2.zhimg.com\u002Fv2-e75e87e04ac6e4b470ef4d3871b10278_r.jpg","summary":"","href":"\u002Fapi\u002Fposts\u002F25168240","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":2,"likesCount":3},"25516863":{"title":"是时候来用 Slush 构建你自己的脚手架了","author":"sqrtthree","content":"\u003Ch2\u003ESlush 是什么？\u003C\u002Fh2\u003E\u003Cp\u003E简单的来说，Slush 就是一个脚手架生成工具。什么？脚手架？这是什么鬼？嗯，脚手架嘛，自然是这个样子咯~\u003C\u002Fp\u003E\u003Cimg src=\"v2-8a12ff20d1da3307a74c5a904e1b7b91.jpg\" data-rawwidth=\"600\" data-rawheight=\"399\"\u003E\u003Cp\u003E什么？你问的是编程中的脚手架呀？啊，这么说吧。身为一个前端开发者，每次新建一个项目的时候是不是要创建好多个文件夹、配置文件？写个文档是不是要创建好多个目录？然而每个项目的结构和配置文件都大同小异，是不是早已繁琐感觉人生无望，失去了活着的意义？\u003C\u002Fp\u003E\u003Cp\u003E\u003Cimg src=\"v2-c063a938046890d548d82c311f56af28.jpg\" data-rawwidth=\"420\" data-rawheight=\"315\"\u003E就在这个时候，Slush 横空出世，能够让你轻松搞定这些繁琐的事情，重新找回人生的意义，你就说吼不吼啊。从此麻麻再也不用担心我整天都在忙着创建文件夹啦。\u003C\u002Fp\u003E\u003Ch2\u003E\u003Cimg src=\"v2-18c72de528f7aa5a68e8e56ac568653d.jpg\" data-rawwidth=\"240\" data-rawheight=\"114\"\u003E道理我都懂，可我大 Yeoman 用的好好的，为什么要换新？\u003C\u002Fh2\u003E\u003Cp\u003E嗯。Yeoman 确实也是一个很好用的脚手架工具，历史悠久。然而它以 Grunt 为基础工具，上手难度大大提高。在轮子层出不穷的前端领域早已是风前残烛。而 Slush 则是基于 Gulp 的 『流式』思想作为基础工具，当你在做定制化脚手架时，Gulp 简单易用的特点则能让你轻轻松松搞定。\u003C\u002Fp\u003E\u003Cp\u003E\u003Cimg src=\"v2-ccda3015f1e884c76a1ec9e855533c42.jpg\" data-rawwidth=\"216\" data-rawheight=\"150\"\u003E噢，这么屌？那该怎么用呢？\u003C\u002Fp\u003E\u003Ch1\u003E说了这么多，我到底该怎么用？\u003C\u002Fh1\u003E\u003Cp\u003E好啦，废话不多说啦，我们赶紧来趁着这个热乎劲看看怎么使用吧。\u003C\u002Fp\u003E\u003Ch3\u003E1. 安装 slush\u003C\u002Fh3\u003E\u003Cp\u003E首先，你得有 NodeJS 环境，什么？连 NodeJS 都没装？赶紧回家洗洗睡吧。如果你已经有了呢，你就可以通过 npm 直接将 slush 安装到全局环境下啦：\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003Enpm install -g slush\n\u003C\u002Fcode\u003E\u003Cp\u003E安装完了之后，你可以执行下面这行命令来确保安装成功：\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003Eslush -v\n\u003C\u002Fcode\u003E\u003Cp\u003E如果你能看到输出了一个版本号，就说明已经安装成功啦。下面我们就来看一下如何使用吧。\u003C\u002Fp\u003E\u003Ch3\u003E2. 安装第三方脚手架\u003C\u002Fh3\u003E\u003Cp\u003E在使用 slush 创建项目之前，你得先安装一些别人开发好的脚手架。安装好脚手架之后才能根据脚手架生成约定好的项目结构哟。\u003C\u002Fp\u003E\u003Cp\u003E咦？不知道有什么脚手架？快来 \u003Ca href=\"http:\u002F\u002Fslushjs.github.io\u002Fgenerators\" data-editable=\"true\" data-title=\"大厅\"\u003E大厅\u003C\u002Fa\u003E 里找找吧。\u003C\u002Fp\u003E\u003Cp\u003E很好，你已经找到了自己喜欢的脚手架了，我们快来安装它吧。打住，提醒你一下，脚手架要安装到全局环境下才有效哟。\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003Enpm install -g slush-react-starter-kit\n\u003C\u002Fcode\u003E\u003Ch3\u003E3. 开始生成项目吧\u003C\u002Fh3\u003E\u003Cp\u003E现在我们已经安装好需要的一切了，终于可以开始创建项目啦。\u003C\u002Fp\u003E\u003Cp\u003E首先，创建一个项目文件夹并进入文件夹中：\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003Emkdir my-first-slush-project\ncd my-first-slush-project\n\u003C\u002Fcode\u003E\u003Cp\u003E其次，执行 slush 生成命令：\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003Eslush react-starter-kit\n\u003C\u002Fcode\u003E\u003Cp\u003Ereact-starter-kit是什么鬼？我们安装的明明是 slush-react-starter-kit 呀。没错，在生成项目的时候，slush 后面跟的脚手架名字中是不带 slush 关键词的。就是这么任性。\u003C\u002Fp\u003E\u003Ch2\u003E\u003Cimg src=\"v2-f43ebf94be422fa21493f6cd3b4ba6de.jpg\" data-rawwidth=\"700\" data-rawheight=\"393\"\u003E没找到好使的，宝宝想要自定义怎么办？\u003C\u002Fh2\u003E\u003Cp\u003E当然了，可能你翻遍了整个大厅都没找到自己想要的，迫切想要自己定制一个脚手架怎么办呢？且听我慢慢道来。\u003C\u002Fp\u003E\u003Cp\u003E其实很简单啦，Slush 脚手架就是一个普通的 npm package，唯一需要注意的有这么几点：\u003C\u002Fp\u003E\u003Col\u003E\u003Cli\u003E名字要以 slush-* 的方式\u003C\u002Fli\u003E\u003Cli\u003Epackage 中包含一个 slushfile.js 文件\u003C\u002Fli\u003E\u003Cli\u003Epackage.json 文件中加上 slushgenerator 关键词方便别人检索\u003C\u002Fli\u003E\u003Cli\u003E模板文件放在 templates 文件夹中\u003C\u002Fli\u003E\u003Cli\u003E别忘了安装 gulp 作为本地依赖啦\u003C\u002Fli\u003E\u003C\u002Fol\u003E\u003Cp\u003E假设你已经按照上面这些约定做好了准备工作，那么接下来我们就可以搞一件大新闻啦。\u003C\u002Fp\u003E\u003Ch4\u003E第一步：创建模板文件\u003C\u002Fh4\u003E\u003Cp\u003E首先，你要将模板文件（就是运行脚手架之后生成的项目文件）全部放到 templates 文件夹中\u003C\u002Fp\u003E\u003Ch4\u003E第二步：在 slushfile.js 文件中编写任务流。\u003C\u002Fh4\u003E\u003Cp\u003E前面已经说到 Slush 是基于 Gulp 作为基础工具的，所以你只需要按照 Gulp 的使用方法在 slushfile.js编写任务流就可以啦。\u003C\u002Fp\u003E\u003Cp\u003E咦，好像有点不太对，既然是用 Gulp，那么 gulpfile.js 文件呢？\u003C\u002Fp\u003E\u003Cp\u003E\u003Cimg src=\"v2-7d47555e108473df8a3965936ac00f01.jpg\" data-rawwidth=\"168\" data-rawheight=\"136\"\u003E这里确实是不需要 gulpfile.js 文件啦，因为 Gulp 任务都在 slushfile.js 文件中写啦，Slush 会帮你自动驱动 Gulp 的啦。\u003C\u002Fp\u003E\u003Cp\u003E好了，那么 slushfile.js 文件中的到底该怎么写呢？放着我来，小哥亲自给你示范一下：\u003C\u002Fp\u003E\u003Cbr\u003E\u003Ccode lang=\"text\"\u003Evar gulp = require('gulp'),\n    install = require('gulp-install'),\n    conflict = require('gulp-conflict'),\n    template = require('gulp-template'),\n    inquirer = require('inquirer');\n\ngulp.task('default', function (done) {\n  inquirer.prompt([\n    {\n    \ttype: 'input',\n    \tname: 'name', \n    \tmessage: 'Give your app a name', \n    \tdefault: gulp.args.join(' ') \u002F\u002F 从运行参数中获取值作为 name 的默认值。\n    },\n    {\n    \ttype: 'confirm',\n    \tname: 'moveon',\n        message: 'Continue?'\n    }\n  ]).then(function (answers) {\n    if (!answers.moveon) {\n      return done();\n    }\n    \n    gulp.src(__dirname + '\u002Ftemplates\u002F**')      \u002F\u002F 使用脚本所在的目录作为相对路径。\n      .pipe(template(answers))                 \u002F\u002F Lodash 模板支持，可以方便的在模板中进行插值。\n      .pipe(conflict('.\u002F'))                    \u002F\u002F 当文件冲突时，询问是否覆盖。\n      .pipe(gulp.dest('.\u002F'))                   \u002F\u002F 输出到执行命令的当前文件夹中。\n      .pipe(install())                         \u002F\u002F 使用 `bower install` 或 `npm install` 执行安装操作。\n      .on('end', function () {\n        done();                                \u002F\u002F 告知完成。\n      });\n  });\n});\u003C\u002Fcode\u003E\u003Cp\u003EPS: 去哪里发现诸如 [inquirer](https:\u002F\u002Fgithub.com\u002FSBoudrias\u002FInquirer.js) 这么好用的 package 呢？你可以关注下 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fsqrthree\u002Fawesome-npm-packages\" data-editable=\"true\" data-title=\"github.com\u002Fsqrthree\u002Fawesome-npm-packages\"\u003Egithub.com\u002Fsqrthree\u002Fawesome-npm-packages\u003C\u002Fa\u003E 哟。\u003C\u002Fp\u003E\u003Cp\u003E现在就已经搞定啦，接下来怎么使用呢？因为 Slush 调用的是全局环境下的脚手架，但是目前我们的脚手架并不在全局环境中，然而你还没发布这个脚手架，不能直接工作 npm install -g 进行全局安装，所以显然是不！能！用！啦！哈！哈！哈！\u003C\u002Fp\u003E\u003Cp\u003E\u003Cimg src=\"v2-1daaec5da98ccf4a8597dae4a0fdcf4f.jpg\" data-rawwidth=\"180\" data-rawheight=\"180\"\u003E别着急砸电脑嘛，我们还有一个办法捏。那就是通过 npm link 命令将当前脚手架挂载到全局环境中啦。你只需要在当前文件夹中执行 npm link，搞定，收工（前提是 package.json 已经写好）。然后就可以随便找个文件夹安装我们上面说的方法使用脚手架啦。\u003C\u002Fp\u003E\u003Ch2\u003E生成 Slush 脚手架的脚手架\u003C\u002Fh2\u003E\u003Cp\u003E尽管自定义一个脚手架已经非常方便了，但是细心的你会发现几乎每个脚手架之间 slushfile.js 也都大同小异，只是 templates 文件夹中的模板文件不一样，所以呢，你懂得😉。\u003C\u002Fp\u003E\u003Cp\u003E\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fchrisenytc\u002Fslush-generator\" data-editable=\"true\" data-title=\"slush-generator\"\u003Eslush-generator\u003C\u002Fa\u003E 就是这么一个让我们来生成 Slush 脚手架的脚手架。有了它，创建自定义脚手架的时候异常方便。\u003C\u002Fp\u003E\u003Ch4\u003E第一步：安装 slush-generator\u003C\u002Fh4\u003E\u003Cbr\u003E\u003Ccode lang=\"text\"\u003Enpm install -g slush-generator\u003C\u002Fcode\u003E\u003Ch4\u003E第二步：创建并进入自定义脚手架的文件夹\u003C\u002Fh4\u003E\u003Ccode lang=\"text\"\u003Emkdir my-slush-generator\ncd my-slush-generator\n\u003C\u002Fcode\u003E\u003Ch4\u003E第三步：运行任务：\u003C\u002Fh4\u003E\u003Ccode lang=\"text\"\u003Eslush generator\n\u003C\u002Fcode\u003E\u003Cp\u003E之后会让你回答一些问题，在回答过之后，你的自定义脚手架目录就已经生成好啦。接下来只需要在 templates 文件夹中放置你需要的文件就好了。\u003C\u002Fp\u003E\u003Ch2\u003E查看已经安装好的脚手架\u003C\u002Fh2\u003E\u003Cp\u003E直接输入 slush 即可看到已经安装过的脚手架：\u003C\u002Fp\u003E\u003Ccode lang=\"text\"\u003E➜  slush\n[slush] Installed generators\n[slush] ├── generator (0.2.11)\n[slush] └── koa2 (0.1.0)\n\u003C\u002Fcode\u003E\u003Cp\u003E怎么样？是不是已经迫不及待的想要尝试了？\u003C\u002Fp\u003E\u003Cp\u003E\u003Cimg src=\"v2-bffc2be18087b75e32c47c66db28e65c.jpg\" data-rawwidth=\"580\" data-rawheight=\"580\"\u003E喔，对了，少侠留步，差点忘了告诉你一件事情：\u003Cimg src=\"v2-11e1602d55a7580593d43b5cdbed118c.jpg\" data-rawwidth=\"1000\" data-rawheight=\"1000\"\u003E\u003C\u002Fp\u003E","updated":new Date("2017-03-02T03:29:55.000Z"),"canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":0,"state":"published","isLiked":false,"slug":"25516863","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2017-03-02T11:29:55+08:00","links":{"comments":"\u002Fapi\u002Fposts\u002F25516863\u002Fcomments"},"url":"\u002Fp\u002F25516863","titleImage":"https:\u002F\u002Fpic4.zhimg.com\u002Fv2-8a12ff20d1da3307a74c5a904e1b7b91_r.jpg","summary":"","href":"\u002Fapi\u002Fposts\u002F25516863","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":0},"25790205":{"title":"作为一个开源软件的作者是一种什么样的感受？","author":"sqrtthree","content":"\u003Cblockquote\u003E\u003Cul\u003E\u003Cli\u003E原文地址：\u003Ca href=\"https:\u002F\u002Fnolanlawson.com\u002F2017\u002F03\u002F05\u002Fwhat-it-feels-like-to-be-an-open-source-maintainer\u002F\" data-editable=\"true\" data-title=\"What it feels like to be an open-source maintainer\"\u003EWhat it feels like to be an open-source maintainer\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E原文作者：\u003Ca href=\"https:\u002F\u002Ftwitter.com\u002Fnolanlawson\" data-editable=\"true\" data-title=\"Nolan Lawson\"\u003ENolan Lawson\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E译文出自：\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fsqrthree\u002Fsqrthree.github.io\u002Fissues\u002F13\" data-editable=\"true\" data-title=\"作为一个开源软件的作者是一种什么样的感受？\" class=\"\"\u003E作为一个开源软件的作者是一种什么样的感受？\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003Cli\u003E译者：\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fsqrthree\" data-editable=\"true\" data-title=\"根号三\"\u003E根号三\u003C\u002Fa\u003E\u003C\u002Fli\u003E\u003C\u002Ful\u003E\u003C\u002Fblockquote\u003E\u003Cp\u003E你的门外有几百人在排队。他们耐心地等待着你回答他们的问题、抱怨、pull requests 和 功能请求。\u003C\u002Fp\u003E\u003Cp\u003E你想帮助他们，但是现在你要关闭它们。或许你已经辛苦工作了一整天，或者你累了，或者你只是想和你的家人、朋友享受一个周末。\u003C\u002Fp\u003E\u003Cp\u003E但是如果你访问 \u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fnotifications\" data-editable=\"true\" data-title=\"github.com\u002Fnotifications\"\u003Egithub.com\u002Fnotifications\u003C\u002Fa\u003E，它会持续地提醒你有多少人正在等着你：\u003C\u002Fp\u003E\u003Cp\u003E当你设法找到一些空闲时间后，你打开门并接待了第一个人。他们非常善意。他们尝试使用你的项目，但是在 API 上遇到了一些困惑。他们将自己的代码粘贴到了 GitHub 评论区中，但是他们忘记或不知道怎样格式化它，所以他们的代码非常混乱，难以阅读。\u003C\u002Fp\u003E\u003Cp\u003E你热心地将他们的代码放到一个代码块中，因此它们有一个很友好的格式。但是你仍然需要阅读很多代码。\u003C\u002Fp\u003E\u003Cp\u003E并且他们对于问题的描述也很难理解。或许这个人不以英文为母语，或者他们有残疾使得他们很难通过写作进行沟通。你不确定。总之，你很难理解他们发布的这一段话。\u003C\u002Fp\u003E\u003Cp\u003E你很疲劳。你看了看排在他后面的数百个其他人。你可以花费半个小时来理解这个人的代码，或者你可以选择跳过他，只是给他一些教程和文档的链接，这些有助于帮助解决他们的问题。你也可以善意的建议他们尝试 Stack Overflow 或 Slack channel instead。\u003C\u002Fp\u003E\u003Cp\u003E队伍里的下一个人脸上皱起了眉头。他们抱怨你的项目浪费了他们两个小时，因为某个明确的 API 并没有像宣传的那样如期工作。他们刻薄的言辞让你感觉很不舒服。\u003C\u002Fp\u003E\u003Cp\u003E你不想在这个人上浪费太多的时间。你简单地回复了：“这是一个开源项目，并由志愿者志愿维护”。如果代码中有一些 bug，请提交一个可复现的测试代码或者一个 PR。\u003C\u002Fp\u003E\u003Cp\u003E接下来的一个人遇到了一个非常普遍的错误，但是有一个很容易的解决方案。你知道你之前见过这个错误，但是就是想不起来解决方法写在了哪里了。Stack Overflow? wiki? 邮件？Google 了几分钟以后，你粘贴了一个链接并关闭了这个问题。\u003C\u002Fp\u003E\u003Cp\u003E下一个人是一个长期贡献者。你从各种社区论坛和兄弟项目中认出他们的名字。他们遇到了一个非常深奥的问题，并且提出了一个 pull request 来解决它。不幸地是，这个问题太复杂了，以至于他们的 PR 包含了好几段文字来解释它。\u003C\u002Fp\u003E\u003Cp\u003E你的眼睛再一次瞥了外面仍然在排队的几百人。你知道这个人在他们的解决方案上做了大量的工作。并且这可能是一个合理的方案。Travis 的测试已经通过了。所以你想回复一个 \"LGTM\" (译者注：Looks Good To Me.) 然后合并它。\u003C\u002Fp\u003E\u003Cp\u003E然而，在之前你曾吃过这样的亏。你曾经合并过一个 PR 但是并没有完整的评估它。最后它让你很头痛因为你没有预料到它带来的问题。或许通过了测试，但是性能下降了十分之一。或者造成了内存泄漏。又或者因为导致了这个项目的 API 过于复杂以至于对新用户来说容易困惑。\u003C\u002Fp\u003E\u003Cp\u003E如果你现在合并了这个 PR，明天你可能会遇到更多的问题，因为你通过解决了这个人的（非常边缘的）问题打破了别人的工作流。因此你决定先将它滞后，稍后当你有更多时间时你会再处理它。\u003C\u002Fp\u003E\u003Cp\u003E下一个人发现了一个新 bug，但是你知道它实际上是一个兄弟项目中的 bug。他们说这个问题阻止他们运行应用。你知道这是一个大问题，但是只是许多问题中的一个。你现在没有时间来马上修复它。\u003C\u002Fp\u003E\u003Cp\u003E你回复到看起来这真的是一个问题，但是在另一个 repo 里报告这个问题更合适。因此你关闭了这个问题，并把它复制到另一个 repo 里面。然后添加一个评论建议应该从代码中的哪个地方开始修复它。虽然你怀疑他们是否会这样做。（很少啦）。\u003C\u002Fp\u003E\u003Cp\u003E接下来的一个人只是说了一句“这是什么状态？”。你不确定他们到底在讨论什么，因此你查看上下文。他们关于一个项目中的长期 bug 的评论导致 GitHub 评论板很冗长。许多人不同意这个问题原本的解决方案，所以它产生了很多讨论。\u003C\u002Fp\u003E\u003Cp\u003E在这个问题上有 20 多条评论，你需要花费很长的时间才能阅读并理解所有的内容。所以你只是回复了一句：“对不起，这个问题已经打开了有一段时间了，但是到现在还没有人解决它。我们仍在试着理解问题的范围。一个 pull request 或许是一个好的开始。”\u003C\u002Fp\u003E\u003Cp\u003E下一个人仅仅是一个 GreenKeeper bot。这个处理起来很轻松。除了这个特定的仓库有着相当脆弱的测试，并且因为一个看起来并不真实的原因而测试失败了，因此你为了能够通过测试必须重新启动它。你重启了测试并尝试提醒自己在稍后 Travis 能运行它时检查一下。\u003C\u002Fp\u003E\u003Cp\u003E接下来的那个人打开了一个 pull request，但是是在一个相当活跃的仓库上，因此另一个维护者已经提出了反馈。你瞥了一眼大致过程，你相信这个维护者能够处理这个问题。因此你将它标记为已读并继续下一步。\u003C\u002Fp\u003E\u003Cp\u003E下一个人在运行时出现了一个你之前从未见过的大问题。但不幸的是他们没有提供一丁点关于问题实际发生时的细节。用了什么浏览器？Node 的哪一个版本？项目的哪一个版本？使用哪些代码能重现它？你要求他们重新提供一些细节并关闭了这个页面。\u003C\u002Fp\u003E\u003Ch3\u003EThe constant stream\u003C\u002Fh3\u003E\u003Cp\u003E过了一段时间后，你已经处理了一二十个这样的情况。但是仍然还有几百个人在等待着。但是现在你已经感到精疲力尽了。每一个人都有他自己的抱怨、问题、或者是新需求。\u003C\u002Fp\u003E\u003Cp\u003E从某种意义上来说，这些 GitHub 通知就是一个关于你的项目的的不间断消极流。没有人会因为对你的所作所为感到满意时打开一个 issue 或者是 pull request。他们只会在发现缺少一些东西时才这样做。尽管你只花费很少的时间来阅读他们的这些通知，但是仍然能让你在精神上和情绪上感到疲惫不堪。\u003C\u002Fp\u003E\u003Cp\u003E你的伴侣观察到你在做完这些事情之后总是脾气很坏。或许你发现自己在毫无原因的嘲笑她，仅仅是因为你的心情很糟糕。“如果从事开源工作会让你如此生气，为什么你还要做呢？”她问道。你也没有一个很好的答案。\u003C\u002Fp\u003E\u003Cp\u003E你可以休息一下。事实上你可以已经尝试过了。之前有一次，你远离 GitHub 给自己放了一两周的假期，仅仅是为了自己的心理健康。但是你知道你结束这种情况的原因是因为有数以百计的人们在耐心地等着你。\u003C\u002Fp\u003E\u003Cp\u003E如果你保持关注并处理你的 GitHub 通知。或许每天只有 20-30 消息，更容易处理一点。然而你让它们在那里堆积，所以现在堆积了上百个。你感到内疚。\u003C\u002Fp\u003E\u003Cp\u003E之前，由于某种原因，你真的让这些问题堆积在那了。你或许已经看到有一个问题已经几个月没有回复了。通常，当你回过头处理这样的问题时，打开这个问题的人一直没有给你回复。或者他们回复到：“我放弃了你的项目用了另外一个，所以问题已经解决啦。”这让你感觉很糟糕。但是你理解他们的失望。\u003C\u002Fp\u003E\u003Cp\u003E从以往的经验中你学到了：对于这种陈旧的问题，更实际的回复是仅仅说一句：“我关闭这个旧问题啦，如果这个问题还存在或者你能提供更多细节的话请再重新打开。”通常情况下都没人回复。有时有人回复了一下，然而只是很生气的抱怨你让他们等待了这么长时间。\u003C\u002Fp\u003E\u003Cp\u003E现在你尝试更频繁的关注你的通知。数百人的等待队伍实在是太长了。你渴望这个队伍的人数能够降到一百，或十几，甚至有一个 \u003Ca href=\"https:\u002F\u002Ftwitter.com\u002Feranhammer\u002Fstatus\u002F616137191131996160\" data-editable=\"true\" data-title=\"空收件箱\"\u003E空收件箱\u003C\u002Fa\u003E 的神话。所以你继续。\u003C\u002Fp\u003E\u003Ch3\u003E招募一个新的贡献者\u003C\u002Fh3\u003E\u003Cp\u003E像上面这样处理了很多问题之后，即使你最终清空了收件箱，仍然会以积压了大量的 bug 和 pull request 而收尾。标签可以对你有所帮助 —— 例如，你可以将一个问题标记为“需要再现”、“存在测试用例”或者 “good first patch”。“good first patch” 尤其有帮助，因为他们常常吸引新的贡献者。\u003C\u002Fp\u003E\u003Cp\u003E然而，你已经注意到了，通常吸引新贡献者的那些问题都是非常容易的问题 —— 对那些问题而言努力记录并且解释如何修复它比你只是自己修复它还重要。你创建了一些这样的问题，因为你知道让新人参与到开源项目中是值得的，当 pull request 的作者告诉你“这是我第一次向开源项目做出贡献”时，你会感到很开心。\u003C\u002Fp\u003E\u003Cp\u003E但你知道他们不太可能会回来。通常这些人不会成为长期贡献者或维护者。你想知道你是否做错了，是否有更多你力所能及的可以引领新贡献者并且帮助减轻你的负担的事情。\u003C\u002Fp\u003E\u003Cp\u003E在你的项目中就有一个几乎是自我维持的。你已经好几年没有碰过它了，但是有一个维护小组在答复每一个问题和 PR，因此你不用关注它。你极其感激这些维护者。但是你并不知道是因为做了什么事情才有如此多的维护者参与这个项目中，而其他的项目则以你独自负责而收尾。\u003C\u002Fp\u003E\u003Ch3\u003E展望未来\u003C\u002Fh3\u003E\u003Cp\u003E你不愿意创建新项目了，因为你知道它只会增加你的维护负担。事实上，有一个对立的现象是：你越成功，你从 GitHub 通知那里得到的“惩罚”就越多。\u003C\u002Fp\u003E\u003Cp\u003E你仍然可以回忆起创作的激情，从头开始写一个新项目解决之前未解决的问题时的那种喜悦。但是现在你不喜欢这种喜悦，因为任何新项目都会从旧项目中窃取时间。你想知道是否到了正式放弃你的一些旧项目或者 \u003Ca href=\"http:\u002F\u002Funmaintained.tech\u002F\" data-editable=\"true\" data-title=\"标记它们为不再维护\"\u003E标记它们为不再维护\u003C\u002Fa\u003E 的时候了。\u003C\u002Fp\u003E\u003Cp\u003E你想知道在你崩溃之前你还能坚持多久。你之前考虑将开源作为你的日常工作。但是和一些真正将开源作为生活的人聊过之后，你知道这通常意味着可以将一个具体的开源项目作为你的日常工作。但是对你来说并没有什么帮助，因为你有横跨多个领域的 \u003Ca href=\"https:\u002F\u002Fwww.npmjs.com\u002F~nolanlawson\" data-editable=\"true\" data-title=\"几十个项目\"\u003E几十个项目\u003C\u002Fa\u003E，这些都在争夺你的时间。\u003C\u002Fp\u003E\u003Cp\u003E你最想要的是有更多的项目可以自我维护。你尝试按照所有的 \u003Ca href=\"https:\u002F\u002Fmedium.freecodecamp.com\u002Fhow-to-attract-new-contributors-to-your-open-source-project-46f8b791d787\" data-editable=\"true\" data-title=\"最佳实践\"\u003E最佳实践\u003C\u002Fa\u003E：你有一个 CONTRIBUTING.md 和一个行为准则，你热情地向所有提交高质量的 PR 的人发出所有者权限。为每一个项目都做这些事情是非常辛苦的，所以，你并没有对自己想象中的那样勤奋。\u003C\u002Fp\u003E\u003Cp\u003E自从你知道开源经常被视为一个为享有特权的白人（就像你一样）开设的高档俱乐部后，你也因为这个而感到内疚。所以你因为没有付出足够的努力来修复这些问题而焦虑。\u003C\u002Fp\u003E\u003Cp\u003E无论如何，你感到内疚：你知道你可以帮助某人解决他们的问题但是反而让他们的问题腐烂了几个月然后关闭它而内疚，或者因为知道某个人在你的仓库发起了他们的第一个 pull request 但是你并没有时间去回复它而内疚，并且你可能还因此致使他们对开源长期感到气馁。你因自己的所作所为而感到内疚，因没能做到的事情感到内疚，并且不想招募更多的人来分担你不幸的内疚经历。\u003C\u002Fp\u003E\u003Ch3\u003EPutting it all together\u003C\u002Fh3\u003E\u003Cp\u003E我上面所说的都是基于我自己的经验。我不能声称代表了所有从事开源软件事业的人，但是这确实是我的感受。\u003C\u002Fp\u003E\u003Cp\u003E我已经从事开源很长一段时间了（大概 7 年吧），我一直很讨厌抱怨这些事情，因为我担心这会被理解为应当更明白事理的人的夸张的牢骚。毕竟，这种情况不是我自己导致的么？只要我愿意我可以随时离开 GitHub，我对任何人都没有义务。\u003C\u002Fp\u003E\u003Cp\u003E还有，我不应该感激么？我在开源方面的工帮助我在社区获得了名声。我被邀请在一些会议上演讲。我在推特有成千上万的粉丝在听我说的话并且高度尊重我的意见。可以说我之所以得到了微软的工作就是因为我在开源方面的经历。我该抱怨谁？\u003C\u002Fp\u003E\u003Cp\u003E并且，我知道已经有很多跟我类似的人放弃了。那些人在无影无踪地消失之前曾积极地合并 pull request、修复问题，在博客上写一些关于他们项目的文章。对于其中一些人，我甚至都不会在他们的 repo 上打开 issue，因为我知道他们不会回复。我不会抱怨这些事情，但是我担心我也会走他们的老路。\u003C\u002Fp\u003E\u003Cp\u003E我已经采取了很多自我保护措施。我不再使用 GitHub 的通知界面了，我使用邮件进行过滤。因此我可以基于项目（不维护的会被忽略掉）或通知类型（提到我的和我评论过的通常优先级更高）分类我的通知。由于通知是邮件，这也有助于我离线工作并且在一个地方处理所有的事情。\u003C\u002Fp\u003E\u003Cp\u003E我经常会收到蓝色级别的邮件让我支持一个我已经停止维护的项目（例如，我每月至少收到一封关于\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fnolanlawson\u002Fcatlog\" data-editable=\"true\" data-title=\"这一个项目\"\u003E这一个项目\u003C\u002Fa\u003E，通常情况下我不会回复他们。我也倾向于忽略我博客文章里面的评论、Stack Overflow 答案的回复和邮件里的问题。我基本上也不再关注那些我觉得别的维护者已经做得很好的 repo。\u003C\u002Fp\u003E\u003Cp\u003E这种情况如此令人沮丧的原因之一是，我越来越觉得处理问题远比实际维护一个项目要花费时间。换句话说，我经常只有时间阅读一个问题然后说：“对不起，我现在没时间看这个。”仅仅是这样的回复就已经占用了我原本为开源预留的大部分时间。\u003C\u002Fp\u003E\u003Cp\u003E\u003Ca href=\"https:\u002F\u002Fgithub.com\u002Fblog\u002F2111-issue-and-pull-request-templates\" data-editable=\"true\" data-title=\"Issue templates\"\u003EIssue templates\u003C\u002Fa\u003E, \u003Ca href=\"https:\u002F\u002Fgreenkeeper.io\u002F\" data-editable=\"true\" data-title=\"GreenKeeper\"\u003EGreenKeeper\u003C\u002Fa\u003E, \u003Ca href=\"https:\u002F\u002Ftravis-ci.org\u002F\" data-editable=\"true\" data-title=\"Travis\"\u003ETravis\u003C\u002Fa\u003E, \u003Ca href=\"https:\u002F\u002Fdocs.travis-ci.com\u002Fuser\u002Fcommon-build-problems\u002F#travis_retry\" data-editable=\"true\" data-title=\"travis_retry\"\u003Etravis_retry\u003C\u002Fa\u003E, \u003Ca href=\"http:\u002F\u002Fcoveralls.io\u002F\" data-editable=\"true\" data-title=\"Coveralls\"\u003ECoveralls\u003C\u002Fa\u003E, \u003Ca href=\"http:\u002F\u002Fsaucelabs.com\u002F\" data-editable=\"true\" data-title=\"Sauce Labs\"\u003ESauce Labs\u003C\u002Fa\u003E… 针对开源维护的问题，有这么多的技术解决方案。我非常感激它们。如果没有这么多自动化工具，我将不能保持专注。但在某些时候，相比技术问题，你遇到的更多的是社交问题。一个人成不了规模。我甚至不在 \u003Ca href=\"https:\u002F\u002Fgist.github.com\u002Fbcoe\u002Fdcc961b869bbf6685002\" data-editable=\"true\" data-title=\"前 100 个 npm 贡献者\"\u003E前 100 个 npm 贡献者\u003C\u002Fa\u003E 之列，就已经感觉到了压力。简直不敢想象那一百个人的感觉是什么样的。\u003C\u002Fp\u003E\u003Cp\u003E我已经告诉我的伴侣，当我们决定开始拥有一个孩子时，可能我还是退出开源比较好。我不知道我怎样才能在撑起一个家庭和从事开源之间平衡时间。我预计最终这个将解决我的问题：核选择。我只是希望它能以一个积极的形式到来，像是开启了我的生活新篇章一样，而不是一个消极的形式。\u003C\u002Fp\u003E\u003Ch3\u003E结尾词\u003C\u002Fh3\u003E\u003Cp\u003E如果你已经阅读到这里，并且对开源社区的问题和潜在的解决方案感兴趣，或许你会想看看 \u003Ca href=\"https:\u002F\u002Ftwitter.com\u002Fnayafia\" data-editable=\"true\" data-title=\"Nadia Eghbal\"\u003ENadia Eghbal\u003C\u002Fa\u003E 写的 \u003Ca href=\"http:\u002F\u002Fwww.fordfoundation.org\u002Flibrary\u002Freports-and-studies\u002Froads-and-bridges-the-unseen-labor-behind-our-digital-infrastructure\" data-editable=\"true\" data-title=\"“Roads and Bridges”\"\u003E“Roads and Bridges”\u003C\u002Fa\u003E，这可能是对问题最清晰和最彻底的分析。\u003C\u002Fp\u003E\u003Cp\u003E我也乐于接受建议，但是请记住，我非常不愿意在我的开源项目中将钱和劳动成果混在一起（由于傻傻的理想主义的原因）。但是我曾在 \u003Ca href=\"https:\u002F\u002Fvuejs.org\u002Fsupport-vuejs\u002F\" data-editable=\"true\" data-title=\"其他项目\"\u003E其他项目\u003C\u002Fa\u003E 中看到它处理的很好。\u003C\u002Fp\u003E\u003Cp\u003E注意，尽管上边这些都是消极的，但是我仍然感觉开源已经成为了对我的生活很有价值的补充。但我希望这是一个有用的窗口，它可以感受到如何成为你自己的成功的受害者，并且没有完成就放下工作而感到压力。\u003C\u002Fp\u003E\u003Cp\u003E如果说我在开源中学到了一件事，那就是：你做的工作越多，你就越需要工作。我知道这个问题无解。\u003C\u002Fp\u003E\u003Cblockquote\u003E\u003Cp\u003E本文根据 \u003Ca href=\"https:\u002F\u002Ftwitter.com\u002Fnolanlawson\" data-editable=\"true\" data-title=\"Nolan Lawson\"\u003ENolan Lawson\u003C\u002Fa\u003E 的《\u003Ca href=\"https:\u002F\u002Fnolanlawson.com\u002F2017\u002F03\u002F05\u002Fwhat-it-feels-like-to-be-an-open-source-maintainer\u002F\" data-editable=\"true\" data-title=\"What it feels like to be an open-source maintainer\"\u003EWhat it feels like to be an open-source maintainer\u003C\u002Fa\u003E》所译，整个译文带有自己的理解与思想，如果译得不好或有不对之处还请同行朋友指点。如需转载此译文，需注明英文出处：\u003Ca href=\"https:\u002F\u002Fnolanlawson.com\u002F2017\u002F03\u002F05\u002Fwhat-it-feels-like-to-be-an-open-source-maintainer\u002F\" data-editable=\"true\" data-title=\"nolanlawson.com\u002F2017\u002F03\u002F05\u002Fwhat-it-feels-like-to-be-an-open-source-maintainer\"\u003Enolanlawson.com\u002F2017\u002F03\u002F05\u002Fwhat-it-feels-like-to-be-an-open-source-maintainer\u003C\u002Fa\u003E\u003C\u002Fp\u003E\u003C\u002Fblockquote\u003E","updated":new Date("2017-03-15T10:03:47.000Z"),"canComment":false,"commentPermission":"anyone","commentCount":0,"likeCount":1,"state":"published","isLiked":false,"slug":"25790205","isTitleImageFullScreen":true,"rating":"none","sourceUrl":"","publishedTime":"2017-03-15T18:03:47+08:00","links":{"comments":"\u002Fapi\u002Fposts\u002F25790205\u002Fcomments"},"url":"\u002Fp\u002F25790205","titleImage":"https:\u002F\u002Fpic4.zhimg.com\u002Fv2-74fa4abe36653b829ef20c34240098d1_r.jpg","summary":"","href":"\u002Fapi\u002Fposts\u002F25790205","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":1},"34633474":{"title":"不要害怕 Rebase","author":"sqrtthree","content":"\u003Cp\u003EGit 的 \u003Ccode class=\"inline\"\u003Erebase\u003C\u002Fcode\u003E 命令是 Git 用户害怕和迷惑的一个常见源头，特别是那些来自可能更集中的版本控制系统的用户。这很正常。Rebase 是一个不可思议又充满魔力的怪兽，一上来不管三七二十一就改变历史。\u003C\u002Fp\u003E\u003Cp\u003ERebase 有点像指针。它是这样一个令人困惑的结构：每个人都在谈论它，但是你并不清楚为什么会有人使用它，然后突然一切都“拍答”一下，整个想法都变得显而易见和难以置信的简单。\u003C\u002Fp\u003E\u003Cp\u003E在这篇文章中我会迫使你“拍答”一下，这样你就可以回到工作中并传播 \u003Ccode class=\"inline\"\u003Egit rebase\u003C\u002Fcode\u003E 的神奇。\u003C\u002Fp\u003E\u003Ch2\u003E究竟什么是 Rebase？\u003C\u002Fh2\u003E\u003Cblockquote\u003EGit Rebase 是一个很简单的工具，用来取出一些在某个地方创建的提交，并假装它们一直是在另一个地方创建的。\u003C\u002Fblockquote\u003E\u003Cp\u003E\u003Cb\u003E好的，我知道了。可是究竟是什么意思呢？\u003C\u002Fb\u003E\u003C\u002Fp\u003E\u003Cp\u003E让我们来看一个例子。我们在这个仓库中有两个分支：\u003Ccode class=\"inline\"\u003Emaster\u003C\u002Fcode\u003E 和 \u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E。\u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E 是基于 \u003Ccode class=\"inline\"\u003Emaster\u003C\u002Fcode\u003E 分离出去的分支，并且在 \u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E 分支上产生了一些提交。\u003Ccode class=\"inline\"\u003Emaster\u003C\u002Fcode\u003E 也发生了移动，因为当你不看的时候，世界并不会停止。\u003C\u002Fp\u003E\u003Cimg src=\"v2-028b10c662732143fba2950db3114f36.jpg\" data-caption=\"\" data-size=\"normal\" data-rawwidth=\"1600\" data-rawheight=\"988\"\u003E\u003Cp\u003E这是目前的状态\u003C\u002Fp\u003E\u003Cp\u003E我们想将一些更改从 \u003Ccode class=\"inline\"\u003Emaster\u003C\u002Fcode\u003E 整合进 \u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E 中，但是我们不想每次执行这个整合时都处理一次令人讨厌的合并提交。\u003C\u002Fp\u003E\u003Cp\u003E\u003Cb\u003ERebase 就是一个让你有能力整合发生在源分支上的更改而不需要执行合并（merge）从而不会产生合并提交的工具。\u003C\u002Fb\u003E\u003C\u002Fp\u003E\u003Cimg src=\"v2-d08ce318cce6fcbf37c0561f2b785dff.jpg\" data-caption=\"\" data-size=\"normal\" data-rawwidth=\"2000\" data-rawheight=\"585\"\u003E\u003Cp\u003E这是 rebase 之后的情况。（fast-forward 版本）\u003C\u002Fp\u003E\u003Cp\u003E\u003Ci\u003ED\u003C\u002Fi\u003E 和 \u003Ci\u003EF\u003C\u002Fi\u003E 两个提交已经被重新放在了 \u003Ccode class=\"inline\"\u003Emaster\u003C\u002Fcode\u003E 的顶部，即当前指向的 \u003Ci\u003EG\u003C\u002Fi\u003E 的前面。你可能会注意到这两个提交实际上已经被重命名为了 \u003Ci\u003ED\u003Ccode class=\"inline\"\u003E* 和 *F\u003C\u002Fcode\u003E\u003C\u002Fi\u003E，并且提交的 SHA-1 值也不一样。这是为什么呢？\u003C\u002Fp\u003E\u003Ch2\u003EGit 中的提交不可变更\u003C\u002Fh2\u003E\u003Cp\u003E一个提交具有一些与之相关的属性：一个父提交、一个时间戳、提交时仓库的快照（“提交”不仅仅是变更集）。这些值是 Git 在计算标识一个提交的 SHA-1 时所用到的。\u003C\u002Fp\u003E\u003Cp\u003E由于提交是不可变的，并且一个 sha-1 应该唯一标识一个提交，因此 Git 需要创建一个新的提交来包含原始提交中相同的仓库快照，但是每个提交都有一个\u003Cb\u003E不同的父提交和时间戳\u003C\u002Fb\u003E。\u003C\u002Fp\u003E\u003Cp\u003E这导致新的提交看起来与原始提交相同，但是具有不同的 sha-1。\u003C\u002Fp\u003E\u003Chr\u003E\u003Ch2\u003E找出提交\u003C\u002Fh2\u003E\u003Cp\u003E当我们从 \u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E 分支上运行 \u003Ccode class=\"inline\"\u003Egit rebase master\u003C\u002Fcode\u003E 时，Git 怎么知道哪些提交需要移动呢？\u003C\u002Fp\u003E\u003Cp\u003E让我们先看看每个分支上的提交的文氏图（Venn diagram）。\u003C\u002Fp\u003E\u003Cimg src=\"v2-b8e33bdc46aca07927458c35b5cc5972.jpg\" data-caption=\"\" data-size=\"normal\" data-rawwidth=\"1600\" data-rawheight=\"1095\"\u003E\u003Cp\u003E从上图中我们可以看到每一个分支都有 \u003Ci\u003EA\u003C\u002Fi\u003E、\u003Ci\u003EB\u003C\u002Fi\u003E 和 \u003Ci\u003EC\u003C\u002Fi\u003E 这几个提交。\u003Ccode class=\"inline\"\u003Emaster\u003C\u002Fcode\u003E 分支还拥有 \u003Ci\u003EE\u003C\u002Fi\u003E 和 \u003Ci\u003EG\u003C\u002Fi\u003E 提交但是 \u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E 分支没有。\u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E 拥有 \u003Ci\u003EF\u003C\u002Fi\u003E 和 \u003Ci\u003ED\u003C\u002Fi\u003E 提交但是 \u003Ccode class=\"inline\"\u003Emaster\u003C\u002Fcode\u003E 分支没有。\u003C\u002Fp\u003E\u003Cp\u003EGit 会做一个减法：\u003Ccode class=\"inline\"\u003E{commits on feature\u002Ffoo} — {commits on master}\u003C\u002Fcode\u003E，来找出正确的提交。这个结果就是 \u003Ci\u003ED\u003C\u002Fi\u003E 和 \u003Ci\u003EF\u003C\u002Fi\u003E。\u003C\u002Fp\u003E\u003Cimg src=\"v2-8dee0891be1f27bffb8e276c6653d326.jpg\" data-caption=\"\" data-size=\"normal\" data-rawwidth=\"1600\" data-rawheight=\"1121\"\u003E\u003Ch2\u003E我们能证明这一点吗？\u003C\u002Fh2\u003E\u003Cp\u003E当然，一个简单方式是使用 \u003Ccode class=\"inline\"\u003Egit log\u003C\u002Fcode\u003E 来看我们从这组减法中得到的确切提交。\u003C\u002Fp\u003E\u003Cp\u003E\u003Ccode class=\"inline\"\u003Egit log master..feature\u002Ffoo\u003C\u002Fcode\u003E \u003Cb\u003E会\u003C\u002Fb\u003E 向我们展示 \u003Ccode class=\"inline\"\u003Ebc1f36b\u003C\u002Fcode\u003E 和 \u003Ccode class=\"inline\"\u003E640e713\u003C\u002Fcode\u003E 提交。\u003C\u002Fp\u003E\u003Cimg src=\"v2-39cb8a7a74e95702d1deb6029693eab6.jpg\" data-caption=\"\" data-size=\"normal\" data-rawwidth=\"1600\" data-rawheight=\"149\"\u003E\u003Cp\u003E如果你在 .. 后省略了一个分支，那么会默认为是当前分支\u003C\u002Fp\u003E\u003Cp\u003E看起来不错。让我们来看看更广泛的视角以确保我不是在糊弄。\u003C\u002Fp\u003E\u003Cimg src=\"v2-df8335d404dcaf6f44a43eea5a3b1da6.jpg\" data-caption=\"\" data-size=\"normal\" data-rawwidth=\"1600\" data-rawheight=\"262\"\u003E\u003Cp\u003E这些 sha-1 看起来很熟悉。\u003C\u002Fp\u003E\u003Cimg src=\"v2-2cdf40ef1dc21740f87e1108f1adfab4.jpg\" data-caption=\"\" data-size=\"normal\" data-rawwidth=\"1600\" data-rawheight=\"261\"\u003E\u003Cp\u003E这里并没有 76f5fd1 和 22033eb，因为我们是从 master 分支的 7559a0b 提交开始分离的。\u003C\u002Fp\u003E\u003Chr\u003E\u003Cp\u003E如果我们现在执行一个 \u003Ccode class=\"inline\"\u003Erebase\u003C\u002Fcode\u003E 到 \u003Ccode class=\"inline\"\u003Emaster\u003C\u002Fcode\u003E，我们会立即看到 \u003Ccode class=\"inline\"\u003E76f5fd1\u003C\u002Fcode\u003E 和 \u003Ccode class=\"inline\"\u003E22033eb\u003C\u002Fcode\u003E 出现在我们在 \u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E 分支上创建出的提交的前面。\u003C\u002Fp\u003E\u003Cimg src=\"v2-4a89b8da5d543fe92cff81a924c9607c.jpg\" data-caption=\"\" data-size=\"normal\" data-rawwidth=\"1600\" data-rawheight=\"214\"\u003E\u003Cp\u003EGit 正在像我们期望中的那样重新应用提交。\u003C\u002Fp\u003E\u003Cimg src=\"v2-356aa7397bd1e9f5f764e3693a1b284b.jpg\" data-caption=\"\" data-size=\"normal\" data-rawwidth=\"1600\" data-rawheight=\"360\"\u003E\u003Cp\u003E看起来熟悉吗？\u003C\u002Fp\u003E\u003Cimg src=\"v2-3c04a3bf2e6534823c638b280fe64824.jpg\" data-caption=\"\" data-size=\"normal\" data-rawwidth=\"1600\" data-rawheight=\"468\"\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E我们之前见过这个了。\u003C\u002Fp\u003E\u003Cp\u003E我们现在有一个很好的线性历史。你应该能够想到在此刻 fast-forward 的合并会如何发生。\u003C\u002Fp\u003E\u003Cblockquote\u003Erebase 策略还有一个已知的额外好处，就是如果你的 CI 管道（CI pipeline）在功能分支上通过了，那么在合并后的主分支上它也会通过。如果是一个非线性的合并策略，你就不能保证这一点。\u003C\u002Fblockquote\u003E\u003Chr\u003E\u003Ch2\u003E使用强制手段\u003C\u002Fh2\u003E\u003Cp\u003E如果 \u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E 分支已经被推送过（push），并且在 rebase 之后尝试进行另一个推送，Git 会很委婉地拒绝推送。这是为什么呢？\u003C\u002Fp\u003E\u003Cp\u003E\u003Cb\u003EGit 会尽其所能来防止意外覆盖历史，这是一件好事。\u003C\u002Fb\u003E\u003C\u002Fp\u003E\u003Cp\u003E我们来看一下 Git 所认为的 \u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E 分支在远程仓库中的样子是什么样的？\u003C\u002Fp\u003E\u003Cimg src=\"v2-1e745621ad26a40c16ed8175e16e93d7.jpg\" data-caption=\"\" data-size=\"normal\" data-rawwidth=\"1304\" data-rawheight=\"882\"\u003E\u003Cp\u003E现在我们来看一下我们告诉 Git 要做的事情。\u003C\u002Fp\u003E\u003Cimg src=\"v2-eb137f49dda95e87736fa2401da339b8.jpg\" data-caption=\"\" data-size=\"normal\" data-rawwidth=\"1600\" data-rawheight=\"561\"\u003E\u003Cp\u003E\u003Cbr\u003E\u003C\u002Fp\u003E\u003Cp\u003E从 Git 的角度来看，提交 \u003Ci\u003ED\u003C\u002Fi\u003E 和 \u003Ci\u003EF\u003C\u002Fi\u003E 即将丢弃。Git 会给你这样一行友好的信息：\u003Ccode class=\"inline\"\u003EUpdates were rejected because the tip of your current branch is behind\u003C\u002Fcode\u003E。\u003C\u002Fp\u003E\u003Cp\u003E你或许会说，“但是我可以在你这个很棒的图片中清晰地看到，\u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E 分支比之前更进一步了啊。” 这是一个很好的观察结果，但是 Git 只会看到远程仓库中的 \u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E 包含 \u003Ccode class=\"inline\"\u003Ebc1f36b\u003C\u002Fcode\u003E 和 \u003Ccode class=\"inline\"\u003E640e713\u003C\u002Fcode\u003E，但是你本地的 \u003Ccode class=\"inline\"\u003Efeature\u002Ffoo\u003C\u002Fcode\u003E 不包含这些提交。因此为了不丢失这些提交，Git 会委婉地拒绝一个正常的 \u003Ccode class=\"inline\"\u003Egit push\u003C\u002Fcode\u003E，并要求你执行 \u003Ccode class=\"inline\"\u003Egit push --force\u003C\u002Fcode\u003E。\u003C\u002Fp\u003E\u003Chr\u003E\u003Cp\u003E如果你从这篇文章中带走一件东西，那么请记住，rebase 只是简单的查找出在某个分支上创建的提交，然后使用相同的内容但是新的父提交或基础提交（\u003Ci\u003Ebase\u003C\u002Fi\u003E commit）来创建新的提交。\u003C\u002Fp\u003E","updated":new Date("2018-03-16T14:00:39.000Z"),"canComment":false,"commentPermission":"review","commentCount":0,"likeCount":0,"state":"published","isLiked":false,"slug":"34633474","isTitleImageFullScreen":false,"rating":"none","sourceUrl":"","publishedTime":"2018-03-16T22:00:39+08:00","links":{"comments":"\u002Fapi\u002Fposts\u002F34633474\u002Fcomments"},"url":"\u002Fp\u002F34633474","titleImage":"https:\u002F\u002Fpic1.zhimg.com\u002Fv2-57143b3bb0d5fc81acd282e89e685ec4_r.jpg","summary":"","href":"\u002Fapi\u002Fposts\u002F34633474","meta":{"previous":null,"next":null},"snapshotUrl":"","commentsCount":0,"likesCount":0}},"User":{"sqrtthree":{"isFollowed":false,"name":"根号三","headline":"Independent Developer","avatarUrl":"https:\u002F\u002Fpic1.zhimg.com\u002Fa480a10481a6ad79e86607d64c7fb1ed_s.jpg","isFollowing":false,"type":"people","slug":"sqrtthree","bio":"闪光的指压师","hash":"596c7d9fd1f8644260f2b270db3c8d5f","uid":28722241470464,"isOrg":false,"description":"Independent Developer","profileUrl":"https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fsqrtthree","avatar":{"id":"a480a10481a6ad79e86607d64c7fb1ed","template":"https:\u002F\u002Fpic1.zhimg.com\u002F{id}_{size}.jpg"},"isOrgWhiteList":false,"isBanned":false}},"Comment":{},"favlists":{}},"me":{},"global":{"experimentFeatures":{"ge3":"ge3_9","ge2":"ge2_1","androidPassThroughPush":"all","sEI":"c","nwebQAGrowth":"experiment","qawebRelatedReadingsContentControl":"close","liveStore":"ls_a2_b2_c1_f2","nwebSearch":"nweb_search_heifetz","newSignBg":"new","rt":"y","isOffice":"false","enableTtsPlay":"post","newLiveFeedMediacard":"new","newMobileAppHeader":"true","growthSearch":"s2","hybridZhmoreVideo":"yes","nwebGrowthPeople":"default","nwebSearchSuggest":"default","qrcodeLogin":"qrcode","enableVoteDownReasonMenu":"enable","isShowUnicomFreeEntry":"unicom_free_entry_off","growthBanner":"default","newMobileColumnAppheader":"new_header","androidDbRecommendAction":"open","zcmLighting":"zcm","androidDbFeedHashTagStyle":"button","appStoreRateDialog":"close","mobileFeedGuide":"block","default":"None","isNewNotiPanel":"no","adR":"b","wechatShareModal":"wechat_share_modal_show","uRe":"1","androidProfilePanel":"panel_b"}},"columns":{"next":{},"FETalk":{"pins":[],"followersCount":6,"creator":{"bio":"闪光的指压师","isFollowing":false,"hash":"596c7d9fd1f8644260f2b270db3c8d5f","uid":28722241470464,"isOrg":false,"slug":"sqrtthree","isFollowed":false,"description":"Independent Developer","name":"根号三","profileUrl":"https:\u002F\u002Fwww.zhihu.com\u002Fpeople\u002Fsqrtthree","avatar":{"id":"a480a10481a6ad79e86607d64c7fb1ed","template":"https:\u002F\u002Fpic1.zhimg.com\u002F{id}_{size}.jpg"},"isOrgWhiteList":false,"isBanned":false},"topics":[{"url":"https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F19550901","id":"19550901","name":"前端开发"},{"url":"https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F19573936","id":"19573936","name":"前端工程师"},{"url":"https:\u002F\u002Fwww.zhihu.com\u002Ftopic\u002F19590813","id":"19590813","name":"前端入门"}],"activateState":"activated","href":"\u002Fapi\u002Fcolumns\u002FFETalk","acceptSubmission":true,"firstTime":false,"postTopics":[{"postsCount":1,"id":369,"name":"CSS"},{"postsCount":1,"id":2517,"name":"Git"},{"postsCount":1,"id":5265,"name":"开源项目"},{"postsCount":1,"id":5288,"name":"GitHub"},{"postsCount":1,"id":17921,"name":"前端开发工具"},{"postsCount":1,"id":26191,"name":"开源社区"},{"postsCount":1,"id":155650,"name":"前端工程化"},{"postsCount":1,"id":155768,"name":"gulp"},{"postsCount":1,"id":156416,"name":"React"},{"postsCount":1,"id":156764,"name":"Web Components"}],"pendingName":"","avatar":{"id":"v2-2d48fa9e882bfe42ae96829a734f32e5","template":"https:\u002F\u002Fpic1.zhimg.com\u002F{id}_{size}.jpg"},"canManage":false,"description":"","pendingTopics":[],"nameCanEditUntil":0,"reason":"","banUntil":0,"slug":"FETalk","name":"FETalk","url":"\u002FFETalk","intro":"起始于 Javascript 而不止于 Javascript","topicsCanEditUntil":0,"activateAuthorRequested":"none","commentPermission":"anyone","following":false,"postsCount":4,"canPost":false,"FULLINFO":true}},"columnPosts":{"FETalk":{"entity":["34633474","25790205","25516863","25168240"]}},"columnSettings":{"colomnAuthor":[],"uploadAvatarDetails":"","contributeRequests":[],"contributeRequestsTotalCount":0,"inviteAuthor":""},"postComments":{},"postReviewComments":{"comments":[],"newComments":[],"hasMore":true},"favlistsByUser":{},"favlistRelations":{},"promotions":{},"switches":{"couldSetPoster":false},"draft":{"titleImage":"","titleImageSize":{},"isTitleImageFullScreen":false,"canTitleImageFullScreen":false,"title":"","titleImageUploading":false,"error":"","content":"","draftLoading":false,"updating":false,"globalLoading":false,"pendingVideo":{"resource":null,"error":null}},"drafts":{"draftsList":[],"next":{}},"config":{"userNotBindPhoneTipString":{}},"recommendPosts":{"articleRecommendations":[],"columnRecommendations":[]},"env":{"edition":{"baidu":false,"yidianzixun":false,"qqnews":false},"isAppView":false,"appViewConfig":{"content_padding_top":128,"content_padding_bottom":56,"content_padding_left":16,"content_padding_right":16,"title_font_size":22,"body_font_size":16,"is_dark_theme":false,"can_auto_load_image":true,"app_info":"OS=iOS"},"isApp":false,"userAgent":{"ua":"CCBot\u002F2.0 (http:\u002F\u002Fcommoncrawl.org\u002Ffaq\u002F)","browser":{},"engine":{},"os":{},"device":{},"cpu":{}}},"message":{"newCount":0},"pushNotification":{"newCount":0}}