#5 楼 @lilu

一个前端想从中选一个，他选了 js 实现的 less。

一个 Ruby 后端想选一个，他选了 Ruby 实现的 scss。

于是，less 写的比较好看，因为它背后的社区是前端社区，scss 背后是 ruby 社区，看项目主页就可以知道了。

当然，这不一定，但是 less 现在就有 twitter bootstrap 做例子，如果只是想拿别人的框架来用，那么这些好看的框架是用 less 的可能性更大。如果是想自己写，那么两个都无所谓。

我现在是用 scss。

#7 楼 @kenneth 因为你要的都在 README

我考虑很久也没想出 scss 和 less 哪个有决定性的优势，所以先用着 Rails 默认的 scss。

因为 less 是 js 实现，比较亲前端社区，可能导致 less 阵营写的网页会漂亮一些。

不知道楼主解决问题的步骤是怎么样的，是不是：

1. 发现问题
2. 发帖提问

邮箱只有一个列表，已发送、草稿是客户端做的吧（web 也是邮箱服务的客户端），垃圾邮件是邮箱服务过滤的，不进入邮件列表，也就不通过 pop3 获取了。

#7 楼 @zlx_star 是的，给 feed 用。用了几个 atom 文件，有点重复，不知道有无更好的实现方法。

#7 楼 @dreamrise 我的工作环境是 Linux，如果强迫给我一部只能装 windows 但是有 usb 接口的电脑，我自然要用 LiveUSB 了。

可以把 Linux 放到 U 盘里面跑啊

配色是什么？

#5 楼 @zlx_star 哪个文件？tech 目录只有 atom，实际的日志还是用 年/月/日/标题 做 Url

#7 楼 @Peter 还要改掉路由，把 /users/location 显式指到那个 action

match "users/location/:id", :to => "users#新action名", :as => :location_users

PS：这里应该用 get 不用 match，可以顺便改了

编码问题似乎是 moped 这个 gem 的问题，升到 1.0.1 解决。

bundle update moped

也就是替换成 fcitx 就没问题了吧。

#3 楼 @cxh116 ibus 很可能不是输入法框架最好的选择

《神仙打架，CJK 输入法之争》 http://codecampo.com/topics/556

jekyll 是有 cateogry 的。我的做法 https://github.com/chloerei/chloerei.com

建议看看《AV》（又名青春梦工场）这部片，回答一下这个问题：

请问我们公司为什么需要你？

新的默认头像是谁的「公然猥亵头」啊

我觉得带外框的布局不适合用圆头像，形状会冲突的。圆头像可以用在无边框的布局。

回复数提示的颜色感觉蒙了层灰。

把 action 的名字改掉就行了。

邮箱是可修改的，需要密码验证。

而且我认为 username 也是可修改的，否则 github 登录的用户名太难看了。

第 3 方登录还有一些问题没考虑好，比如必填字段缺失了怎么办（我建议进入表单页面而不是填随机值），登录状态绑定第 3 方的时候返回的是已绑定的帐号怎么办，一个用户可不可以绑定多个第 3 方帐号……诸如此类的问题。不过 Ruby China 主要是想促进交流，把帐号系统搞得那么复杂有点得不偿失。

现在随机 email 和密码的结果是，如果修改邮箱需要密码，那么第 3 方登录的用户既不能修改邮箱也收不到密码重置邮件。

不过我也没时间改这块地方。

首先感谢楼主报 bug，不过信息量太大我没提炼出要点是什么。到底是：

1. 做了什么修改？
2. 出了什么错误？

#1 楼 @bhuztez 可以看看 guard 这个工具有没有什么能用的上的，比如自动测试 https://github.com/guard/guard/wiki/List-of-available-Guards

#7 楼 @superbatironmans5 ~> 的意思就是大于版本号最末位，等于倒数第 2 位。

mongoid 没有实现 find_by_xxx 动态方法

User.where(:email => email.downcase).first

#46 楼 @santochancf 不能做这个功能，那样会满屏无意义回复。

#20 楼 @jayliud 出处是老江香港训记者

yield content_for

#22 楼 @ery 我这推广了一段时间 rebase，现在组员对 git 熟练起来后，开始提倡 merge 和 rebase 并用。rebase 用在短小的补丁 commit 上，merge 用在特性开发，因为希望 logs 不单要线索清晰（merge 点不要太多），也要反映协作情况（多线进行），不然一个两天前的 commit rebase 到了今天的 commit 上，以后查看起来会很奇怪。

#20 楼 @ery 比如 B 分支有两个人在上面开发，然后把 B rebase A。

这里有详细例子 http://git-scm.com/book/zh/Git-%E5%88%86%E6%94%AF-%E5%88%86%E6%94%AF%E7%9A%84%E8%A1%8D%E5%90%88

一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。
如果你遵循这条金科玉律，就不会出差错。否则，人民群众会仇恨你，你的朋友和家人也会嘲笑你，唾弃你。