#7 楼 @yangyanhao #9 楼 @hhuai 真是好办法
#14 楼 @ery 服务器的本质就是调用 cpu 根据状态机逻辑处理各种数据。
如果你有 1000 个任务,但都是要 cpu 做的,那么别搞花样,老老实实按顺序做是最快的方式,后面排队的任务也只好等着。
但是,如果这里面有任务被 hold 住了(比如读写 socket),那么这时 cpu 是空闲的,后面排队的任务处于有计算资源却不能使用的状况,这才是我们常说的“阻塞”,这时候我们最好的选择是——保留当前任务的工作现场,然后让 CPU“跳过”这个任务先做下一个。
然而,如何保留现场?具体做起来却不那么简单,这里有两个问题:1、如何处理多核/多 CPU 之间的共享;2、是否由 OS 负责
发现写起来有些收不住了,强行打住,有空补充
#11 楼 @lucky215 作为补充,我一直在更新 wiki 页面( http://ruby-china.org/wiki/hangzhou_ruby_tuesday ),但是也仅限于记录话题、关键字和资料连接(如果有的话)
是的
@clc3123 说的没错,事件驱动这事已经不新鲜了,ruby 程序员可以找 EventMachine 这个库看看。
另外补充一下,处理后释放的是当前线程(所以可以单线程工作),但是 tcp 连接等资源还是继续保留的
这篇帖子的知识量不小,放到推荐内容如何?
很不错的文章
#8 楼 @ery 既然说了就展开一下,我最近正好在分析团队里不同应用进行的基于数据的测试,目前比较了几个方案以后的基本感受是——“没有包打天下”的方案,数据量大的时候只有 sql 能满足性能要求,这对于计算密集型的、分析型的应用很适合,但是基于 sql 的数据准备对于数据关联复杂的业务很不合适,主要是缺少数据 build 的时候不能基于业务模型......
所以我现在对团队的建议是——“混合策略”,同时使用三种方式:
另外,如果有兴趣,建议你了解一下 scenariotest,杭州 ruby tuesday 的活动有一次就是讲这个的,它每次构造数据后会缓存用过的 sql,所以重复使用性能应该比 factory_girl 好,当然,对于巨量的数据,它依然还是比较慢的,算是个折衷
#11 楼 @clearJiang 淘宝的 cdn 不妨试试,现在也用了比较久了,应该靠谱。另外说句闲话,我建议对 kissy 感兴趣的人模仿 jquery-rails.js 写一个 kissy 的 adapter,这对 js 程序员应该不难,好处就是以后 rails 的各种 helper 都可以对 kissy 透明使用了
今天迁到 octopress 上了,托管是 github,source 放上去挺好,本机可以随时挂掉
#45 楼 @poshboytl 这个本来是见仁见智,不过看到 @soloara 的几个帖子,让我觉得澄清概念也很重要,而且和现实的问题也有联系,比如你就不必纠结怎么设计 URL 更好,而是看你的框架服务的社区惯例,如果揪着 Rails 的惯用法不放,未免买椟还珠
#41 楼 @yedingding 其实我贴的那两个链接基本上已经很清晰了,论文讲了推导过程,反而容易绕进去。
一句话很难说的完整,简单说我常遇到的误解:我们常说的很多都是基于 http 协议的数据接口,而 REST 风格架构的关键并不在这里,它的特点是“先验知识”很少。比如 http 算是个 REST 的实现,它的对 agent 的要求很简单——理解 POST/GET/PUT/DELETE/... 即可,agent 在不理解具体的业务情况下依然能够演化出复杂的应用,而做到这一点是靠了所谓“超文本驱动“的思路,比如:浏览器访问一个网站,只有首页是用户输入的,拿到首页之后,可以根据获取的页面上的链接进一步驱动用户的行为,这个风格保证了标准客户端的产生,也让服务端可以自由演化,说实话,我很佩服这个思想,也是为此才较真。 刚才重新看了大家的 post,其实很多人应该都是理解 REST 的,比如 @hooopo 和 @poshboytl ,欢迎纠正、补充
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"