https://github.com/huacnlee/homeland 以 Rails Engine 的方式的嵌入式论坛组件 http://ruby-china.org/topics/2661

心智成长问题在国内很普遍。学习了。@jasl

生成的 SQL 语句就是非法的。

update feedbacks set mark = 0 where feedbacks.'' = 1

你注意了吗？

我也觉得，在美国有一个合伙人更实际一点。不然很难打开国外市场。但从外面的案例看，别人都是在网上宣传的啊，难道老外也作弊？

楼主用的 Fedora，好

提交一个 issue 到 ruby issue list.这样你可以得到更专业的回复。

见过老板和楼主，很 nice。加油。

谢谢分享

@jarorwar thanks for share.

@fsword 在你面前，我还是弱弱的。哈哈，那天来北京，ping 我，一起吃饭。

刚好达标。共勉。

楼主，把论坛里的编辑器换了吧

@yedingding 一直没吭声，欢迎来北京。你太潮了，希望家有空房的 Ruby 爱好者提供帮助。

@funfriend 全开，散热也是刚刚的。这是因为新的 mac pro 增加了新的散热通道在底部，这种小细节一般用户是没法注意到的。如果你确实不太了解，请擦亮眼睛，慢慢体会一下： http://www.apple.com.cn/macbook-pro/design-retina/

这是工业艺术品和工具的完美结合。请无视任何设计上的问题，关键你的预算是多少，对于新手买高端是最划算的，就是因为你不懂这样那样的适配，所以你选择最贵的，当然就可以满足你任何需求。当你使用过一台之后，你在选择的时候就不会再纠结了。that's all.

我是 i7/8G 新款。秒杀一切你所提到的应用场景。

@ZeroCool 新机器都有这个过程。我之前一直在 Fedora 用了三年，都把 mac 的安装给忘了。之后领导说给我配个 mac。我就同意了。这买回来后配置也在一个地方遇到坑了。分享一下给你参考： Ruby on Rails development with Mac OS X Mountain Lion http://createdbypete.com/articles/ruby-on-rails-development-with-mac-os-x-mountain-lion/

其中有一段不要安装：

mkdir ~/.bundle
touch ~/.bundle/config
echo'BUNDLE_PATH: vendor/bundle' >> ~/.bundle/config

这里有问题，配置后反而出未知错误。

@blackanger 你在理想化的推广。不如强制性地推广来的快。很多时候好的习惯并不是所有人能理解和赞成。

@aphantee 社区是需要爱护的，对社区没价值的东西还是三思再发。尤其是只对自己有好处的。

@aphantee 这对 Ruby-China 有啥好处，你说说。你连个链接都没推荐么。

@doitian 是的，我怀疑有时工程师确实没心情写代码，不在状态。休息是最好的方式。

@Yujing_Z 谢谢分享。你忽略了你的团队成员 > 2。当你的团队特别小 (2,3 个人) 的时候，Code Review 对工程师的自律是很高的。唯有坚持才能得到好的收益。

广告贴。。。节操啊

c[:when].(words) 这个无法接受。难理解。

@Yujing_Z A 和 B 做 Code Review，会遇到问题：A 今天效率不错，B 效率差一点。A Review 完 B 的代码，自己的代码 B 没心情 Review 的情况。但项目要前进不能等人的。

你一周 7 天有 5 天可能会 code review，是做了 Review 还是没做。你如果一直坚持 review，就没有遇到问题吗？你是如何解决的。我觉得这才是讨论的价值。

@Yujing_Z

1. Code Review 的价值楼主已经阐述，我的体会是实践反馈。我的意思是说并不是所有人会认可 Code Review。PM 并不关心 Code Review，也无需为它负责。Code Review 应该由 Project Tech Leader 来坚持和推广。
2. 关于小团队有没有 QA，都应该测试的话题已经跑题了，我们这里讲的是 Code Review
3. A 和 B 的 Code Review，不是 Pair programming，一边些代码，一边些测试。所以我怀疑你 (@Yujing_Z ) 有没坚持过 Code Review。两个人的 Code Review 也会遇到问题，A 今天效率不错，B 效率差一点。A Review 完 B 的代码，自己的代码 B 没心情 Review 的情况。但项目要前进不能等人的。

我觉得这个问题可以在具体一点，那就是你期望的特效是那种类型的。比如你期望

1. 动态拖拽在前端先 Render 出来呢，
2. 还是给出一个字段表单让用户先择的组件后在后端 render。

接下来，我的问题是，你是希望完全用 Ruby 技术来解决它，还是可以 mashup 其他技术。 建议多考虑一下你的问题，问问 Google，基本上你会有一个大概的答案。

我们使用 gerrit 作为专门的 code review 工具。和楼主一样认可代码审核的效果。在实施过程中也发现一些阻力：

1. 不写代码的项目经理或产品经理在 review 例会上，为了项目进度往往要求去掉这个 Code Review，因为它不产出价值。有问题应该让 QA 来把关。在时间紧张，任务重的情况下直接忽略测试，把问题推给 QA。
2. 在 Code reivew 的过程中，发现并不是所有的开发者都是喜欢 Code Review 的。他们更倾向于新任务的第一次交付。有问题等 QA 测出来再说。
3. 当团队只有 1 个到 2 个人这种规模，Code Review 变成了 A 看 B,B 看 A。很累。不如转向多写功能测试。每一个 Bug 写一个测试覆盖它。

应该都在这里了。

我用的是原生的 Ctrl + n 来补全。

客户端的 ICON 都不贴，尽贴微博的内容，对推广无意义么。