@nevill rails 不是打包起来嘛，每个文件里面做 namespace 就好了。

前端的话现在好像还是挺缺的。做好前端感觉不容易。 首先是对基础的理解，css spec 要看一遍，盒模型，html，html5，ajax，jquery，js 语言的特性要足够了解。 然后是分支的技术，html5，svg，webgl 什么，看用到什么了。 知道如何做各种效果，瀑布流，图片墙，如何搭建复杂的富应用，前端渲染什么的。 还有就是要知道不同浏览器，手机，平板上面渲染会出现的问题，如果中国的话还有解决 IE 兼容性，这一块是前端最麻烦的地方。。

typo: websties -> websites

排名只会在人们的心中。外面的排名不重要。

让我想起 lisp 里面两种实现类的方法 (伪代码莫纠结)：

(send :favorite idea user)

(send idea :favorite user)

话说为什么不能自己搭一个？然后做好验证就可以了？还有就是如何测邮件到达率？没有量化的东西感觉没有底啊。

我觉得 cnepub 挺好的。

打个 banner 宣传献血？不过有种裹挟用户的感觉。技术区就不要搀和这些事情了。

刚才看 http://ruby-china.org/topics/10345 里面有关于 ruby 底层的： http://thinkinginruby.group.iteye.com/group/wiki

还找到一本，原文是日文的： http://rhg.rubyforge.org/

#1 楼 @zgm 对，ruby 的入门书很多，深入的书不多。python 有源码解析的那本国人出的，ruby 好像没有看到多少。

坐等自己的账户被他们干掉。。

楼上霸气！小小年纪就沉稳不惊！

#21 楼 @darkbaby123 同感。

当然要写注释！并且很多情况下代码是不能说明问题的！几种状况：

• 业务代码。代码本身阐述的是做什么，很多时候需要介绍清楚代码为什么做这个事情。这个时候需要注释。单独的函数可以放在函数上面，复杂的功能还需要整理一个 wiki，然后在代码里面加上 wiki 的链接。
• workaround。针对一些 bug 或者问题的修正，看代码是说不清楚的，需要加上 bug 号。
• 有背后的技术底蕴。比如利用到了 etags 或者浏览器的一些特性，一行代码能够解决，但是写的时候查阅了很多资料，这个时候要把思考过程附上让后来人能够理解这个代码后面的事情。

#8 楼 @quakewang 恩，这个资料留作备用，一般的状况不需要去动了~ #3 楼 @huacnlee 是大部分都需要（用的东西真是太复杂了啊），能够去掉的都不消耗什么资源。。20ms 级别的优化需要做的话估计就不用 rails 了~ #4 楼 @huacnlee 就是现在的网站，主要的大头还是各种 assets 的下载时间以及美国服务器的响应时间啊。。

#1 楼 @Rei 当然没有，只是想知道这里有多少潜力可挖。

#2 楼 @kenshin54 Thanks! 看这些就好了，我自己写了一个页面把这些都列出来，还有加上一些 Settings 的参数，如果能够把 Rails.configuration 的东西挖出来就好了。

找到一个，评估中： https://github.com/Applicat/rails_info

http://www.lettermelater.com/

#11 楼 @wushexu 404

#5 楼 @kenshin54 恩，用起~

#3 楼 @kenshin54 恩，思考了一下，是这样。但是 rails4 为什么要提供这个东西？让用户自己弄 dsl 吗？就没有一个最佳实践可以直接用？

#8 楼 @iBachue 服务器集群下面的 log 也是需要汇总的啊。我主要还是针对本地调试以及简单的单机器部署。

#6 楼 @NonTwitter 管理后台就是类似 web 上面看，并且可以提供一些优化，比如点击直接跳到代码什么的。

#3 楼 @iBachue 当然是这样，不过如果生产环境下面能够看到 log 不是更好？

#4 楼 @NonTwitter 这个也是后台？

恩，看起来可以做一个 gem 来处理这个问题。

翻了一下，发现是 gitlab 自己实现的方式，并且这个方式不是很好用的样子。。

基本的常识又重新说了一遍。我觉得文章里面的好东西就是给出了 ruby 下高并发的解决方案以及实际使用案例，这样在未来的项目选型的时候可以用来作为支撑材料。