• #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 封邮件“的需求,他需要的是一封一封的认真看(原子操作),或者”获取重要邮件”(批量操作),后者就可以抽象出的新的资源。 为什么人会比较特别?因为人的生理结构决定他在交互时不可能附加太多的信息,比如删除这件事,一个人可以指定删除几封邮件,但如果高达几百封则很容易出错,于是需求变成了搜索,又是不同的资源...

  • Chrome 是不是比光速还快? at 2012年03月04日

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

  • 如何高效利用 GitHub at 2012年03月04日

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

  • 如何高效利用 GitHub at 2012年03月04日

    很不错的文章

  • Chrome 是不是比光速还快? at 2012年03月04日

    #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 透明使用了

  • Chrome 是不是比光速还快? at 2012年03月04日

    #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 手动?辛苦了!