@haoshanshan 例子都给你了，自己不会看吗？这段代码把数据转为二进制网络序，下一步就是发送。

具体的看 pack : http://ruby-doc.org/core-2.2.0/Array.html#method-i-pack

@haoshanshan

哈，当年写的代码终于有用了：

https://github.com/windy/DIY-pcap/blob/master/lib/diy/parser/mu/pcap/ethernet.rb#L93

这是一段解析以太网 2 层报文的代码，估计比你的需求满足：

ADDR_TO_BYTES = {}
FMT_HEADER = 'a6a6n'
def write io
    dst_mac = ADDR_TO_BYTES[@dst] ||= @dst.split(':').inject('') {|m, b| m << b.to_i(16).chr}
    src_mac = ADDR_TO_BYTES[@src] ||= @src.split(':').inject('') {|m, b| m << b.to_i(16).chr}
    bytes = [dst_mac, src_mac, @type].pack(FMT_HEADER)
    io.write bytes
    if @payload.is_a? String
        io.write @payload
    else
        @payload.write io
    end
end

Linux 电源管理出了问题，可能要关闭 ACPI, 要自己去对应的社区看看。

#6 楼 @redemption

validate do
  if self.b.a.cs.where(name: self.name).first
    errors.add(:name, 'babala...')
  end
end

这种限制在并发的环境下可能出现限制失效的情况，比如你开了多进程实例或者多线程。

#5 楼 @huacnlee 对

支持

# in class C
validates_uniqueness_of :name, scope: :b_id

strong parameters?

#13 楼 @blacktulip 嗯对的

#1 楼 @flowerwrong 正解！

$(document).on('ready page:load', function(){
// blablabla...
})

@jayliud 如果你对 Rails 源码比较熟悉，就会发现无法做到在控制器中删除指定的中间件。所以 @rei 才会说这是 x-y 问题。Rails controller 是注册在 Rack 众多中间件的最上一层，它无力控制其他中间的处理。充其量它可以添加新的中间件，于是 Rails4 中增加了 Controller.use 能力。

这个问题不知道你使用的 Rails 版本，如果是 4.1 以上 ( 也许 3.x 的某个版本就已经 Ok 了 ), stream & live 两种处理方式已经自动设置了 no-cache.

如果不能升级 Rails 版本，也许手动设定 headers['Cache-Control'] = 'no-cache' 就会 OK, 也许你特定的版本 Rack::Cache 中间件不会检查这个头部会覆盖它，这样你就只能去研究下它的源码，看看有无可以 Hack 的手段：actionpack 里面的 lib/action_dispatch/http/cache.rb.

其他的办法，mount 自己的中间件，大家已经热情给你说了，但据我所知，也基本不可行。不如试试我给的建议。

#2 楼 @sensi 检查你们的拼写：should be permit not premit

同 @huacnlee

补充下，如果是用的 mina 或者 capstranio, 类似代码如下：

# Manually create these paths in shared/ (eg: shared/config/database.yml) in your server.
# They will be linked in the 'deploy:link_shared_paths' step.
set :shared_paths, ['config/mongoid.yml', 'config/application.yml', 'log', 'tmp', 'public/uploads', 'public/personal' ]

#42 楼 @mogodb 你关心的问题真奇怪，是用的 vim, 我一直都用的 vim, 而且是命令行版本。

#2 楼 @luckyyang meteor 很有潜力。思路上与 ruby 下的 volt 很像 ( 或者说 volt 是借自 meteor ? )

#4 楼 @liwei78 同城？

#3 楼 @lgn21st 确实如此，把它当做目的就错了，remote 只是形式。目前形势不好，并非技术原因，国内的这个远程办公市场还远远没有形成。

https://ruby-china.org/jobs

到招聘板看看，大多都有薪水期望。具体看能力。

@iBachue 用 Rails Gem 会非常简单，楼主可尝试使用 browser Gem

Just add it to the Gemfile.

gem "browser"
This adds a helper method called browser, that inspects your current user agent.

<% if browser.ie6? %>
  <p class="disclaimer">You're running an older IE version. Please update it!</p>
<% end %>

你问题提的不明不白。在出现问题时，可以尝试在 console 中用 reload! 来重新加载代码，如果好用了，说明 rails c 需要重启。

#38 楼 @iBachue 理念不太合，不多讨论谁优谁劣了。Lina 还有许多待完善的特性，届时应该会更强大。

#36 楼 @iBachue 既然是完整的 API, 返回值要保证正确。验证返回值就很有必要，APIDOC 中也要体现出来。当然，这些校验都是可选的。

配置如下：

# lina config file
Lina.setup do |config|

  #是否开启返回值参数校验
  #config.return_check = true

  #返回值校验时使用的 json schema 版本, 更多: http://tools.ietf.org/html/draft-zyp-json-schema-04
  #config.return_json_schema_version = :v4
end

你不想关闭全局校验的话也可以直接用 return: {} 留空来达到与 Grape 一样的效果。

#34 楼 @iBachue 当然可以自己写个 validator, 但还要生成 APIDOC. Lina 就完全可以做到。实际上这个需求并非多变态，在处理返回值需求的时候，很经常会用到多值 ( 例如 JSON Schema 的 oneOf ), 因为有错误处理，用 Lina 之后，这种 APIDOC 会非常漂亮，而且可以帮助你检查返回值是否符合需求。

另外，Grape 非常不错，适用于纯 API 场景，但集成到 Rails 里总是感觉不舒服，Lina 更适合于 Railser 使用，它本质上就是 Rails + jbuilder 的加强版，既写页面很不错，又写 API 更好 ( Lina 的支持 ), 何乐而不为呢？

#31 楼 @iBachue Grape 非常 Nice, 这个我很认同。如果要讨论 JSON Schema 与 Grape 的 params DSL, 我要说，完备性太重要重要了，试想，如果你要定义一个 JSON 结构，结果 Grape DSL 支持不了怎么办？更何况，我个人认为对于参数自定义的 DSL 并不好用。

比如这个：http://json-schema.org/example2.html, 是否可以用 Grape DSL 定义出来？

而在正常情况下，也有可能遇到这种情况，比如返回值可能有多种 hash, 比如参数里还有子 hash, 子数组。

#4 楼 @bupo https://ruby-china.org/topics/24369 看最后一段。

#26 楼 @iBachue Grape 确实已经非常好，不过有不少人比如我更喜欢 Rails 风格的 RESTful API 写法，Lina 便是另一个选择。

Hash 的方式不如 DSL 好看，但我没有定义像 Grape 那样定义 DSL, 正是因为表面的简单带来了复杂的 DSL 学习成本高，还不如直接找一个有官方维护的标准，这便是 JSON Schema. 最主要的是完备性。相信如果你看一个 更复杂的 JSON 的例子就明白了：http://json-schema.org/example2.html, 可以看看 Grape 中能否实现这个参数声明。

当然可以。

https://ruby-china.org/topics/24369 正好这篇帖子里面列举了 Ruby 中写 API 的几个框架。

#14 楼 @dimi 要多向你们学习~

#20 楼 @bxd602 logo 还有很多改进空间，欢迎给个设计图 PR.

#24 楼 @flowerwrong 你说的是在线模拟测试吧，很多 API 都会有登录限制，或权限约束，还不如直接用一些 chrome 插件或者本地的方案比如：

• @fredwu 的 api_taster
• chrome 插件：advanced-rest-client

所以，不太考虑这个特性。

#16 楼 @kayakjiang 嗯，收到，#1 楼 也提了这个建议。接下来几个版本还会不断改善 APIDOC, 最后应该还要做到可以方便定制。

#11 楼 @yesmeck Here: http://guides.rubyonrails.org/engines.html#inside-an-engine