砍 30% 需求，测试覆盖减 30%，30K 我帮你一个月做出来，hoho

同楼上。。。

写文章就如写测试，不狠下心来去练可不行。

台湾人民似乎都比较谦虚好学，也愿意分享，所以常常逛逛他们的小恶魔，感觉比我最近接触的 chiphell 氛围都要好很多，关键是不歪楼，哈哈！

我写 rspec 时，先把一个个 it block 的文字描述写好，block 中间 pending，等要测的方法或流程写了那么个七八条 it 描述了，再开始填 it blocks。带着点挑刺的心态，好像你在 hack github 那种感觉就对了。

作者的新书，Well Grounded Rubyist，也是翻烂了，真的非常好。覆盖 1.9.1。是 R4R 的扩展版本。

1000 个人来申请宽带，他们依次领完了申请表。有个官员就绕着圈专门检查这 1000 个人哪个已经填完申请了，1 号可能是最早进来的，但要是每次官员经过的时候 1 号都没做完，官员就检查下一个，如果下一个先做完了，官员就先让下一个进去办事。所以说 1 号甚至可能是最晚进去的，但他不会阻塞其他人。

#10 楼 @zw963 效果一样，感官可大不同 比如：

class 人
  def self.来一个(&block)
    self.instance_exec &block
  end

  def self.扫地
    puts "扫完了"
  end

  def self.做饭
    puts "做好了"
  end

end

人.来一个 do
  扫地
  做饭
end

这样可以，但你说是不是没有前面那么写来得好？这是艺术问题，不是技术问题。

1.python 和 ruby 都有事件驱动的相关库，node 不也是基于 c 的神马 libev 吗？这模型挺广泛的啊，大公司里的程序员搞这个的好像挺多的 2.连接保持着，不能断了，服务器处理完还走这个连接

Rails 通常的 routes 按理说应该成为原子性的 API 接口，你可以在 controller 中对其进行扩展，同时提供多个资源。但是如果你不想把网站现在用的 controller 搞得一团糟，你可以把 api 的逻辑分开来写，独立成另一套 controller，你可以参考下 teambox 这个在 github 上的项目，虽然我觉得有点重复，不过他们的 api 写法确实能够解决问题。

#12 楼 @fsword CSRF 发生的多吗？虽然没遇到过，但是觉得还是小心点心里舒服。Rails 再强大，也不能覆盖全部的阴暗角落，比如 Oauth2，标准里也提到了 CSRF，不过 Omniauth-OAuth 这样的 gem，并不太关心这个，而且大多数开发者也不关心，这点上，就算 rails 关心也覆盖不了，所以还是自己小心为上

#6 楼 @fsword 谢谢，我也认识到这点了，确实隐藏太深容易让人忽略啊

把节点功能删除了算了，只能选节点，不如自定义 tag

#1 楼 @zhangyuan 太详细了，一看就明白了，谢谢！向你学习，多看源码多实践！

去年看的这本书，看完 rails 就懂了个大概了。最神奇的是，那时才刚开始学编程。。。能写到这么浅显易懂真 TMD 神奇！

写个 js 插件，对应自己的省市数据，本网站都可以用了

具体什么情况要用 union？这个最好简单陈述下你的 schema。single table inheritance 能解决某类问题。 改用 union 就用啊，find_by_sql 该用就用嘛，AR 不支持的数据库指令太多了。

lz 基本都不懂，建议跟个教程走一遍

#1 楼 @ywencn 大侠那应该用什么啊？

#6 楼 @soloara 你这么一说，我看了下 grape，还是比较轻量的，挺不错！Grape 搭配 rails，是不是也是需要把 controller 逻辑重复一遍呢？不过提供简单的 api，确实很容易维护。 我写 api 时，参考过新浪等，发现他们的回传 json 都结构很复杂，一开始不理解，但是后来才知道主要是方便客户端操作，减少请求，纠结就纠结在这两点了。。。 另外我使用了一个 build json 的 gem，这样把 json 的操作放到 view 里去，controller 也显得干净。

墙外的人搞的

#7 楼 @camel 前几天体验了下微软的几款人体工学，发现机械神马的在人体工学面前都是浮云啊。现在还没看到过这种有弯曲或者分离的机械键盘～

正在用 noppoo 的 mini84 的青轴，这款在 linux 下 caplock 灯不亮，mac 下也有问题（据说）。主要喜欢的是 84 键布局，比较精简，放在桌子上占的空间小。 总的来说还是不错的，但是个人觉得更适合 qq 聊天，打起汉字来非常爽；但是写代码的话，对我这种经常打打停停的，感觉还不如戴尔的 8115。。。更不如明基 X 架构，总的来说我最喜欢高端笔记本的键盘感觉。 黑寡妇是黑轴吗？那个根本不能用来打代码。红轴也不行。我都试过，不好用。推荐青轴或者茶轴。机械的轴都一样，不管是 cherry 还是 PLU 还是 Filco，手感都一样，差异主要在细节方面，比如键盘倾斜角，是否有手托，以及键帽。 机械键盘感觉有点被神话了，比如很多人还玩键帽的，囧。。。我买 noppoo 这款前，网上补了不少知识，知道键帽材质还有差异的。。。有 POM，有 KBS，有 PBT 什么的。。。最普通的键盘就是 KBS。如果是一款机械键盘你原配 KBS 你都不好意思说。但实际上嘛。。。那个 PBT 的摸起来凉冰冰的，还不如 KBS 的键帽舒服。 说了好多哦，总之 lz 要是想买就去卖场试试看吧。

什么是纯 api？纯 api 还要用 grape？据说 grape 依托 rails 的。为什么不用 sinatra？

Put，Delete，看你的 api 谁用的，自家手机客户端用或是内部 service api，我觉得你还是直接 put 和 delete。要是浏览器还要 consume 的话，那就换 rails 那种。

API 超难写，个人感觉，做过个玩具，要想写得漂亮就各种纠结。lz 可以看看 Service-Oriented Design With Ruby and Rails 这本书，挺有帮助的。

class CreateUses < AR:Migration
  def change
    create_table :users do |t|
      ...
    end

    execute <<-SQL
      ALTER SEQUENCE users_id_seq
        START 1000000
        RESTART 1000000
    SQL
  end
end

这种问题翻文档就好了。PG 的文档超清晰的。不知道是不是德国人写的，废话相当少。

俺还是新手，就觉得先把 sql 基础打好比较务实，mongo 有看过一点，但是同时学太多总有点畏惧感和不扎实的感觉。如果你招人，肯定还是 sql 系比较好招。 如果从做产品来说，关键的性能瓶颈你可以加缓存，或者剥离 service 单独开发，要是全面铺开 mongo 也没有太大的必要。

#7 楼 @kehao 多谢，开眼界了

#3 楼 @kehao lz 这是拿 em 做什么应用啊？看起来很猛啊