辛苦辛苦，这次由于家庭原因无法参加大会，少贡献了一张 Early Bird，惭愧惭愧。只好预祝大会举办成功了！

也就是说这不是官方维护的咯？那你的朋友说的是对的，最好填 github 地址。封面什么的真心没必要，谁做个扩展还非得整个封面啊。不妨看看 npm grunt 这些项目是如何对待扩展和插件的吧。

你这什么网站啊？

#18 楼 @liwei78 呃，不，那时候我还没写程序呢，在刷盘子……

这已经不是技术问题了，而是你们的产品线设计问题。就像你说的：“用药助手”和“丁香园”连在一块就是怪怪的啊！

那么它们之间到底有没有联系呢？联通此后规划中的各个应用在一起，目标用户交叉的数量范围有多少呢？有没有必要统一呢？会不会出现到后来的确有个别应用就是不能让别的应用的用户能直接登陆呢？这涉及到具体每个应用的业务逻辑了，很难做出一个 yes or no 的回答。

不过，假设决定了就是要做一个统一的用户管理系统，那么最好重新考虑一下产品线，把它们用某种方式联系起来，变成一个平台下的不同模块/分支，这样可以给平台起一个容易理解的名字，让平台作为用户管理的入口，这样就不会产生一开始的问题了。

#8 楼 @wxianfeng 你之前说的是嵌套过深的问题，我说 promise 就是指这个。现在你又改成异步和同步的编程思想差异了……这个我没什么好说的，人和人不一样，你觉得爽的别人未必会觉得。

NodeJS 崛起的势头如此凶猛，有一个很重要的原因是很多很多优秀的前端工程师（不是咱国内那种只写页面的工程师）对这个语言平台和异步编程思想是天然兼容毫无抵触的。你要知道有大量的前端工程师都没有或者很缺后台语言的经验和背景，不能写后台服务这个事儿把他们都给憋坏了，所以 NodeJS 一出现，这帮人就跟疯了似的往上冲，所以繁荣得一点也不意外啊。

#5 楼 @wxianfeng 你应该看一下 promise

layout 本来就是动态的啊……除非，你现在的导航是一个一个手动放上去的？

#21 楼 @aptx4869 那上面那些参赛者有哪个是 jQuery is NOT required？

#19 楼 @qichunren 我不提你可以提啊，冲什么冲？

keywords: homebrew openssl

不会，但是前女友是画素描的，曾经很积极的指导过我一阵子。印象最深的就是她反复强调，刚开始的时候不要追求细节，而是要把注意力放在形状上。她跟我说她画画的时候，比如说画我，那么在她眼里我就是一个一个圆形、方形组成的复杂几何体……Orz

#4 楼 @cisolarix 那就不清楚了，我也是搜索的而已，要不你给 Rails 发个 issue 吧。

#3 楼 @larryzhao 是的，这个也很喜欢！等待 release 再测试，api 变化比较多。

本来想赞 UI 的，仔细一看是 Gmail……

Anyway，这是 Gmail 的问题，看 这里 和 这里

解决办法在 SO 上有人给了一个，不过后面也有人说不赞成这么做。嗯，自己看吧。

先将文件内容转换 -> utf-8，然后再处理。详见：http://ruby-china.org/topics/1223

See this issue to understand why and then follow this solution.

Use Google, always!

默认的测试框架从 TestUnit 变成了 MiniTest，这就是目录结构变化的主要原因，单元测试是一种测试的类型，是不是非得在 unit 目录下一点都不重要。

RSpec 是 BDD 风格的测试框架，两者之间的选择取决于你更偏爱哪种风格。但是从做的事情上来说，它们都可以很好地胜任各种测试工作。

学习写测试当然要花费一定的精力和时间，但是测试能够带来的好处则更多。我觉得你需要花点时间来学习一下，别急着下结论。尽管有一些人声称写测试会增加开发的时间消耗，但很多评测都证明事实恰恰相反，区别在于你到底会不会写，会不会利用测试来减少时间消耗。这不是测试应不应该的问题，而是你的能力是否可以驾驭的问题。

对于初学者，可以不必强求，特别是当你卡在测试环节的时候，你可以跳过去先实现，以后再补测试也可以。事实上，补测试也是一种学习测试的方法，因果倒置之后会有利于你理解当初为什么写不出测试来。绝大多数情况下，写不出测试的原因都是你没有真正理解你想要写的东西是什么，以及它的行为如何。

抽点时间看看 MiniTest 以及 RSpec 的文档吧，看看里面的例子会更有启发。

另外，的确没必要事事都写测试，Ruby on Rails Tutorial 里面的很多测试都是在现实里没必要的。但是你要明白，那是教程，它的主要目标是教会你怎么写，而不是让你完全照搬。

#6 楼 @xds2000 这个……你懂的，我是推荐给英文不好的童鞋的。如果要推荐高质量的算法与数据结构公开课：https://www.coursera.org/course/algs4partI

只说教学水平和表达能力，台大的概率论和北大的算法数据结构这么一比……惨不忍睹呀！真心替咱的大学生担忧。

附一个相关的文章：http://urbanautomaton.com/blog/2013/08/27/rails-autoloading-hell/

后面有 Xavier Noria 的长篇评论。

呵呵

这真是……饱汉子不知饿汉子饥啊！不知道的还以为 LZ 你秀优越来了……

#41 楼 @bhuztez 是的，这么做不是不可以，我写这个东西的目的主要是讲述一下 font-face 声明的解析规则，如果开发者希望有更强的可控性就可以利用这些规则。

单独的 sans-serif 只能是个不犯错的底限，但并非可以预期的上限。

#39 楼 @imlcl 没必要。方法都是一样的，不同的操作系统内置的中文字体就那么几个，谈不上主流不主流，实在是选择太少，而且也不想英文对字体搭配那么讲究（其实还是因为太少……）。

#24 楼 @ytwman 我只是回答你关于求助社区的问题而已。

#18 楼 @xautjzd 纠结这个做什么呢？

简单一点，反过来想：.ssh 目录保存在你的用户目录之下，那么请问有什么理由一定要给它 group 的写权限呢？有什么特别的应用场景吗？

group 可以 赋给属于同组的用户相同的权限，请注意是 可以，也就是说你需要的时候可以给 group 放开写权限，但就这个例子而言，难道你希望其他人在你不知情的时候给你动点手脚吗？还是你觉得你自己无力管理 ssh，需要同组人来帮你忙？

.ssh 的写权限最多就是同一个组的用户将 authorized_keys 改名了导致 user 无法完成身份认证，但是不会有冒充的行为产生。

就“导致 user 无法完成身份认证”这一条便足以有理由去除写权限了，难道你还觉得这是应该的？