啧啧啧，我本来也打算这么干的，可惜目前还无法全职来做，支持吧！

鼓励。

但是不必强求让绿点连成一片，这种形式上的“努力”恰恰应该是程序员所要去避免的追求。除非你同时维护很多项目或者参与了很多开源项目，因而有那么多机会去做有意义的 contribution，否则只是“看上去很美”而已。有很多工程师，特别是做具体产品开发的，在固定的时间段里只是专注一两个 repo，而因为一些 features 憋个三五天没有 push 是非常正常的事情，这并不能够反证其不努力或是不优秀。也有一些人（包括我自己）日常的 contribution 多来自于一些 private repos，而 Github 的 contribution graph 是可以选择不记录私有的 contributions 的，所以别人看不到绿成一片也不能代表他们不活跃。

外界对于一些培训出身学员所贴的标签，大体上并非否认他们的努力（或是天分），真正黑的是那些培训组织，因为他们并没有真正的去培养程序员，他们的做法和理念只会让绝大多数学员变成码农，而且还是不合格的码农。作为学员个体，不用太在意这些标签，也不需要依赖这份经历给自己的影响。如果你自己是一个适合做程序员的人，谁也无法阻止你变得优秀。而优秀这个词，我们通常看中的是它体现出的质量而非数量。

跟你挑个刺，第二段话暴露了你对 SPA 的极大不了解（同时也侧面反映了现在做 SPA 的菜鸡太多），只有路由方面没做好的 SPA 才会出现你说的这种情况，做得好的话任何情况（哪怕是某个极深的路径下打开了一个 modal）都可以通过 URL mapping 还原出 UI 的状态来。

此外，貌似你对 erlang 的文档也有误解？modules 是可以检索出具体的 URL 的。这是 gen_fsm 的：http://erlang.org/doc/man/gen_fsm.html，这是 gen_statem 的：http://erlang.org/doc/man/gen_statem.html

这是机器翻译的吧，一堆的“榆树”好辣眼。

@fangxing204 你这个问题明显是英文不过关而不是没有答案。假设这一次你觉得自己英文水平搞不定 man tar 于是就问别人了，别人也回答你了，那下一次呢？下下次呢？从此以后呢？

别说什么“英语我一定会好好学的，以后就不会问大家了”之类的，学习这种事情只有“现在”，没有“以后”。

我们小时候都听过，“狐狸妈妈会把小狐狸推下山崖，然后让它们自己努力爬上来”，这个道理相信人人都明白。固然让你去 RTFM 的人比不上你的爸妈，可事情的性质并没有什么不同。别人没想那么多，你自己就不能 think one step further？

我的观点一直都是：问答双方互不相欠，你要问就问，他愿答就答；答得好看精彩并不是因为你长得美，你是占了便宜的；答得简单甚至丑陋也不是因为你长得丑，只是今天运气欠佳。如果你觉得回答的人对你不友好，直接怼上去没商量不就完了吗？如果你觉得回答的人对你的恩情犹如滔滔江水连绵不绝……你也不需要做什么，公道自在人心，社区会尊重每一位贡献者的价值。

至于说要成立委员会引导社区走向和文化的，我有一句话：强扭的瓜不甜。

因为真正贡献答案的人其实一直都在贡献着，也许有时候因为太忙了顾不上，然而这本来就是义务奉献你无法要求他们更多。而那些惯于群嘲、鄙视、乱喷的人根本属于另外一个群体，即使你建立了一套社区导向，也不可能让他们遵守你的引导。最终你会发现你只有“惩罚”这条路可以走，但你以为他们在乎吗？最后的结果很可能就是激化矛盾，在一定的时间范围内搞得社区乌烟瘴气，“民不聊生”，然后那些本来“甘当孺子牛”的人们也就悄悄离开了。

冲动是好的，可惜没在点子上。若说具体的措施，reputation 算是一个不错的方法吧，但是 reputation 机制想做好真的不容易。

所以你要解决的不是“喜欢把生产环境密码提交到 github”的问题，而是他为什么“说了很多次也不听”的问题。

这个，你问我，我也不了解杭州行情啊……如果是我的话，我心里会对自己有个大致的评价吧，然后直接去跟领导谈呗。不过你要明白一件事情，你认为的你的价值和领导眼中的你的价值，这是两件事情。如果事情不如你预料的那么顺利，也不用灰心，最好能和你领导谈一下，了解自己缺失的部分到底在哪里。

我跟你举个例子吧，我在我的老东家任职的后期，我自己评估自己的技术能力已经超过业务的实际需求了（老东家是为一些中小企业做定制项目的，所以实际中的技术要求并不太高），换句话说：尽管我认为自己更厉害，但现实的需求却是换一个人来也能够替代企业对我的需求，所以这时候你去要一个符合你能力的薪水，领导未必会认同这一点——倒不是他不认同你的技术能力，而是觉得他的业务需求不值得花这么大成本来雇佣一个能力虽强却无用武之地的人。

怎么办呢？我换个角度，既然业务实现上已经用不上更高的技术能力了，那我就把精力放在提升整个团队的效率和战斗力上。大体上就是两件事：第一、改造前端的工程体系，提高很多工序的自动化程度，减少各项目在基础设施建设上的消耗；第二、带新人、带实习生，给各项目组提供“物美价廉”的新鲜血液。

这个时候，领导很容易就会给你物超所值的评价，你身边的同事甚至是跨项目组的同事也会给你好评，你不想涨工资都难啊。虽然我后来还是离开了，但不是因为报酬的问题，而是因为个人的技术追求路线，这是题外话了……

总之，对自己的主观评估 + 别人给予的客观评估，综合得到的价值评判才是靠谱的薪资等价物。如果你能对这件事情有一个清楚的认知，那么争取到自己期望的薪水就不是什么难事。

超赞，钩起无数回忆啊～

@freefishz OK，的确已经有人修复，生产环境还没有更新，请再等待一下，不好意思。

@freefishz 我们没有接到短信验证有 bug 的 issue，请问两周前你有跟我们谁提过这个事儿吗？

@babyhai 我已经给你回复了，有问题请继续练习我，谢谢。

在上海？找机会当面请教？

加一下 www，这个域名转向我们最近暂时禁用了一下，因为转移备案的事情。

坐标苏州？介绍一个本地的同性前辈给你认识，如何？rails 她不懂，但是 web 开发她熟。

个例不做探讨，没有意义，没准你倒霉碰上轮值的人大姨妈来了呢？

issue 不是用来问问题的，这不仅仅是 docker，大多数的开源项目都是如此。小型的开源项目由于不是那么忙碌（参与人少），对于 issue 的质量管理相对会松散一些，而规模大一点的项目都会对问问题的 issue 直接关闭处理，在关闭前让你去 google so slack irc forum 等等，这都是例行公事，大可不必如此介意。

如果是使用方面的问题，建议直接走 IM 性质的沟通渠道，比如 slack 或 irc，建议或是讨论可以上论坛（非“急！在线等”类型）。将心比心，如果你让你的用户直接在你们内部的 issue 上对着你问各种使用问题，你会开心？

呃，译者不是我，你 @ 错了

哦，我知道了，你是说我回复里写的吧，了解。

抱歉，年代太久远了，我记不得了，如果我眼神不错，这个应该是 Tomorrow 里的一款。

不用贪多，一本一本看，不用求速，确保你看懂了。

@Vdan 我劝你还是认认真真花上一个月好好补一下 CSS 的基础吧，copy & paste 只能用来忽悠人，你总不能连自己都去忽悠吧？

我可以明确的告诉你，不懂里面的原理，什么套路都救不了你。

我感觉在照镜子……

我再跟你说一个个人的小小感悟，你不妨客观的仔细看看这层楼里的很多回答，你应该能看到这些答案里所反映出来的典型的程序员式的思维，你再和自己的发言对比一下看看。我前面说的写文章式的举一反三和写代码式的举一反三，其实是有含义的。你要去面试的公司包括面试官，可能大多数都是什么样的？他们所在意的东西，比如说“举一反三”，和你理解的是一致的吗？

有的时候应聘也像是打仗，知己知彼方能百战不殆。

是这样的，我赞同你的凭能力论，也的确时间投入比不能准确反应一个人的真实价值。只不过现实是这样的，任何人或者任何公司都很难通过一面或者几面的对话就能分析出应聘者的价值，在这个前提下我说的 四个月和四年 的对比非但不会起到积极作用，反而还会给出负面的影响——除非这个教育模式已经是普遍被认为有效的，如果真是这样也就不存在你的问题了。

所以我觉得更理性的做法是：也许我觉得自己的能力价值是超值的（超出一般性的时间投入比），但是我需要机会证明我的能力价值，所以我宁可自降身价先去获得一个机会，然后快速的证明我胜于我身边的大多数竞争者并且我还能和身边的同事很好的协作。这时候如果公司还不能用客观等价物来评判我的价值，那他们就是眼瞎或者混蛋（这是我需要承担的风险，也是通过面试和现实接触需要我作出判断的因素之一）；反之，则双赢。

我认为一个靠谱的教育者——无论是个体，还是组织，还是政策——都应该负责任的教会学生这样的双赢思维，而不是单方面的告诉学生：按照我的方法来你就能赢。

说真的，能有这些感想的话我不觉得你“不会举一反三”，只不过写文章和写代码不是一件事情罢了。你也谈到了学习方法和技巧，不妨想想为什么写文章能很容易的列出一二三，而写代码就不能了呢？

现实中我也见过很多理论基础不错但一样不会举一反三的程序员，所以我觉得这很可能不是关键。倒是让我个人比较介意的是（不针对你个人），经过四个月培训就出师的程序员，凭什么就可以要一万块钱的薪水呢？我再强调一遍，我不针对个人，我想大部分人都会有这个想法：对啊，凭什么呢？

可能大家会觉得我这话说的不中听，我承认的。我一直对这种……怎么说呢，培养模式？有很大的困惑，让我们看看：用四个月的时间让你拿到四年的水平可以拿到的薪水，是我太傻还是世界变化太快？我相信好的老师肯定能教出好的效果，肯定能节省一定的时间获得更好的效果，只不过我想象力有限罢了，见谅。

等

@darkbaby123 脱离 git，只靠本地 link 探测改变有没有可能？

呵呵，就这件事情可以提现一下像 npm 那种 local modules 的好处。它可以 link 本地的项目作为其他项目的 dependency，连 push 都不需要，本地改本地即时更新。

我们很多组件是写成了 ember addon，但是暂不推送和发布，而是直接 link 到 app 里，这边改 addon，app 那边还会自动刷新。的确很方便。

不知道全局管理的包管理器是否支持 symbolic link，可以试一试看。

我们是自有云服务器，有的项目直接脚本拉取 - 构建-rsync 上去的，有的项目用了 ember-cli-deploy，它的插件特别多，其实找一个和自己需求相近用或者稍微改一下就好了。除了搭载 ember-fastboot 以外，其他都是 build 纯静态资源，部署应该不是什么复杂的事情。

其实是因为我太懒，写的这些东西在读原文的时候脑子里就想到了，但是不想去翻译原文，所以算是借贵宝地一用了。

@lgn21stni 不用不用，这哪儿好意思啊，你太客气了。