#7 楼 @yangyanhao #9 楼 @hhuai 真是好办法

#18 楼 @lgn21st EventMachine 是个好话题阿，你们先上，回头我们杭州也可以拿来聊聊 :-)

#14 楼 @ery 服务器的本质就是调用 cpu 根据状态机逻辑处理各种数据。

如果你有 1000 个任务，但都是要 cpu 做的，那么别搞花样，老老实实按顺序做是最快的方式，后面排队的任务也只好等着。

但是，如果这里面有任务被 hold 住了（比如读写 socket），那么这时 cpu 是空闲的，后面排队的任务处于有计算资源却不能使用的状况，这才是我们常说的“阻塞”，这时候我们最好的选择是——保留当前任务的工作现场，然后让 CPU“跳过”这个任务先做下一个。

然而，如何保留现场？具体做起来却不那么简单，这里有两个问题：1、如何处理多核/多 CPU 之间的共享；2、是否由 OS 负责

发现写起来有些收不住了，强行打住，有空补充

#11 楼 @lucky215 作为补充，我一直在更新 wiki 页面（ http://ruby-china.org/wiki/hangzhou_ruby_tuesday ），但是也仅限于记录话题、关键字和资料连接（如果有的话）

#8 楼 @lucky215 ruby tuesday 是一种非正式的交流方式，更重视当时与会者的交流而不是会后的培训，不输出 slide 不但不可行，而且是一种策略，既可以让大家更容易去开启一个 topic，也是鼓励现场交流。当然，只要不是每次都不来，偶尔缺席没什么大不了的

是的

#2 楼 @vkill ruby 看双飞燕应该更好，我看了镐头书以后只是学了 api 而已

@clc3123 说的没错，事件驱动这事已经不新鲜了，ruby 程序员可以找 EventMachine 这个库看看。

另外补充一下，处理后释放的是当前线程（所以可以单线程工作），但是 tcp 连接等资源还是继续保留的

#16 楼 @soloara 这还要看“客户端”是人还是机器，如果是机器，那么这个不太优雅的方式就够了，如果是人则有可能找到抽象，典型的例子看看 mail 的场景就明白，用户很少有“获取第 1，3，7，8 封邮件“的需求，他需要的是一封一封的认真看（原子操作），或者”获取重要邮件”（批量操作），后者就可以抽象出的新的资源。 为什么人会比较特别？因为人的生理结构决定他在交互时不可能附加太多的信息，比如删除这件事，一个人可以指定删除几封邮件，但如果高达几百封则很容易出错，于是需求变成了搜索，又是不同的资源...

#7 楼 @zw963 原来是这样，我之前理解反了，这个方式没啥问题，不过你还真能定制阿，看来你果然喜欢 unix 的风格，哈哈

这篇帖子的知识量不小，放到推荐内容如何？

很不错的文章

#5 楼 @zw963 那是我误解了，不过你这个方法不太安全，有点反 unix 了，原则上别人可以修改你的二进制文件，虽然拿不到 root，不过攻击你的帐号是足够了

#13 楼 @dotnil 哦，我还以为你忘了呢，这个和 ruby 关系不大，不过可以自己搞一个 gem 出来还是有些成就感的

#8 楼 @ery 既然说了就展开一下，我最近正好在分析团队里不同应用进行的基于数据的测试，目前比较了几个方案以后的基本感受是——“没有包打天下”的方案，数据量大的时候只有 sql 能满足性能要求，这对于计算密集型的、分析型的应用很适合，但是基于 sql 的数据准备对于数据关联复杂的业务很不合适，主要是缺少数据 build 的时候不能基于业务模型......

所以我现在对团队的建议是——“混合策略”，同时使用三种方式：

• 基于 sql 直接灌数据
• 基于 factory_girl 建立独立的测试数据
• 基于现有的 model 直接编写 ruby 代码生成相关数据

另外，如果有兴趣，建议你了解一下 scenariotest，杭州 ruby tuesday 的活动有一次就是讲这个的，它每次构造数据后会缓存用过的 sql，所以重复使用性能应该比 factory_girl 好，当然，对于巨量的数据，它依然还是比较慢的，算是个折衷

#11 楼 @clearJiang 淘宝的 cdn 不妨试试，现在也用了比较久了，应该靠谱。另外说句闲话，我建议对 kissy 感兴趣的人模仿 jquery-rails.js 写一个 kissy 的 adapter，这对 js 程序员应该不难，好处就是以后 rails 的各种 helper 都可以对 kissy 透明使用了

#3 楼 @kgen @zw963没说要共享同一套个性化数据阿，/tmp 目录也是各用各的

今天迁到 octopress 上了，托管是 github，source 放上去挺好，本机可以随时挂掉

#4 楼 @huacnlee dotnil 是谁阿？

#45 楼 @poshboytl 这个本来是见仁见智，不过看到 @soloara 的几个帖子，让我觉得澄清概念也很重要，而且和现实的问题也有联系，比如你就不必纠结怎么设计 URL 更好，而是看你的框架服务的社区惯例，如果揪着 Rails 的惯用法不放，未免买椟还珠

#41 楼 @yedingding 其实我贴的那两个链接基本上已经很清晰了，论文讲了推导过程，反而容易绕进去。

一句话很难说的完整，简单说我常遇到的误解：我们常说的很多都是基于 http 协议的数据接口，而 REST 风格架构的关键并不在这里，它的特点是“先验知识”很少。比如 http 算是个 REST 的实现，它的对 agent 的要求很简单——理解 POST/GET/PUT/DELETE/... 即可，agent 在不理解具体的业务情况下依然能够演化出复杂的应用，而做到这一点是靠了所谓“超文本驱动“的思路，比如：浏览器访问一个网站，只有首页是用户输入的，拿到首页之后，可以根据获取的页面上的链接进一步驱动用户的行为，这个风格保证了标准客户端的产生，也让服务端可以自由演化，说实话，我很佩服这个思想，也是为此才较真。 刚才重新看了大家的 post，其实很多人应该都是理解 REST 的，比如 @hooopo 和 @poshboytl ，欢迎纠正、补充

#10 楼 @huacnlee 以前都是设计为 1024 以内的，他们的场景应该不能太特别吧

Rest本来就只是一种MVC的组织方式 ，看到这句话有些无语。 @poshboytl ，我觉得强调概念还是很必要的

#34 楼 @poshboytl 这个就见仁见智了，我很喜欢老外讨论问题的方式，讨论前先把概念约定一致。

http://www.infoq.com/cn/news/2008/12/restapi-must-be-hypertext-driven

楼主的问题实际上是所谓批量操作的问题

对于批操作，Fielding认为人们觉得需要批操作是因为他们没有理解资源的范围。他指出资源并非存储项（至少不等同于后台中某些存储项），并且同一资源状态可以由多个资源来分担。如果谁发现他需要一个批操作，那么很可能只是因为他没有定义足够的资源。（回复#21）

所以，如果你要简单，那么不必纠结， http://example.com/posts?id=2%2C12%2C14%2C4 没有任何问题。 如果你要追求 REST，那么应该考虑的是，你为什么要用零散的 ID 数组获取一组资源，也许你需要的是定义另外一个资源抽象，这个新资源包括了那些零散的资源

一时想不到，本来差别在 return 上，不过 ruby 函数最后一句就是返回值这个特性似乎让 lambda 的使用场合少了很多

#22 楼 @poshboytl 把概念定义清楚才能不至于浪费口水，而 REST 的概念已经被其作者拨乱反正过一回了，相信大家应该都看过这篇文章 http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven 或者中文翻译 http://www.infoq.com/cn/news/2008/12/restapi-must-be-hypertext-driven ，所以我对社区里这种拿着 data api 说 REST 的讨论很反对，大家应该看出来取名字是一句讽刺，其实数据接口的设计和 REST 没有什么关系，它大量定义了先验知识，更不用说超文本驱动，所以讨论是否更 RESTFul 没有意义。

去掉 REST 这个名字还有一个用处，我们不必为了 REST 而 REST，既然本来就不是 REST 的思路，那么就老老实实设计我们的接口 url，其实，如果不是为了符合 Rails 的路由习惯等等因素，你的 url 怎么设计都行的，只要有规律，确保一致性即可

最后补一句，@soloara 对我的判断只是他个人观点，我没兴趣反驳。不过这是一个社区，他的个人观点显然不能左右我，如果大家都这么想的话，我倒是会考虑离开这个社区

具体情况不清楚，不过提醒一下，有人会误用 force_encoding，而这个 api 是不改变原始的字节数组的

$ irb
1.9.2p290 :001 > "中".each_byte{|x| p x}
228
184
173
 => "中" 
1.9.2p290 :002 > "中".force_encoding('gbk').each_byte{|x| p x}
228
184
173
 => "\x{E4B8}\xAD" 

#7 楼 @huacnlee 手动？辛苦了！