mac os x 的话试试： cd 到项目

brew install libxml2 
brew link --force libxml2
bundle config build.nokogiri --use-system-libraries
bundle install

#2 楼 @lzm420241 class 已经到了不可重用，且会多到重复，无法想象这是什么样的应用场景。我觉得设计方面可能已经存在问题. 如果样式变化比较大且较多，我建议是做容器而不是各种覆盖。举例：.page-article, .page- music, .page-books.

module ObjectExtension
  refine Object do
    def dimension
      self.class == Array ? 1 + self[0].dimension : 0
    end
  end
end

using ObjectExtension

puts [1].dimension # 1
puts [[1], [2]].dimension # 2
puts [[[1,2],[2,3]],[[3,4],[5]]].dimension # 3
puts 'a'.dimension # 0

觉得稍显麻烦，我也推荐个搭配， ss, meow 客户端，实现 pac 系统代理 做一个 meow 的 launchctl 的配置文件，开机加载 alfred 的 proxyswitcher 用来随时切换开关. 命令行 git 可以设置为系统代理. 诸如 brew 之类的使用国内镜像。 这个搭配用了一年多了，没有再为 fq 的事情烦过。

就算这子系统完美无缺，就 win 那 hidpi 的效果和其上的各种 bug, 有什么值得程序员特别是开源栈的程序员迁移上去的？何况 ms 向来弄东西朝三暮四，说停就停，商业目的极为纯粹，谁把自己绑上去谁傻。

国内和 hk 试试青云，国外还是 linode 吧。

开源的基因天然包含分裂 (分支) 特性. ruby 没有标准。mri 被默认认为是事实标准. 开发者思路的不同和不可调和，注定合并不了。ruby mri 仍在变化并认为将来仍会保持变化。而 rubyspec 意图标准化。

对于这类我觉得 yaml 可以用。 存入 YAML.dump(目标), 取出后 YAML.load(目标).

edit: 还是用 Marshal 吧，yaml 比较之下慢一点。

我觉得 rails 栈比较厚是不利因素。要培训一个合格学员的耗时和路径会相对长。开发环境，语言，框架，测试，部署，每个环节都能写出好几本书。针对小而美这个前提下，可能会很费力吧，特别是基础差的学员。

能闻到 code smell 就没什么大的问题了。 有两样是推荐花时间阅读的: https://github.com/JuanitoFatas/ruby-style-guide/blob/master/README-zhCN.md https://github.com/JuanitoFatas/rails-style-guide/blob/master/README-zhCN.md 具体于开发环境上，请选择搭配 rubocop. 我个人的环境是 atom+ rubucop 的 linter. 给我的帮助很大。我觉得称为 ruby 上矫正脊背的背背佳不为过. 阅读他人的代码或者优秀 gem 的代码，也很有帮助。

就问题来看，好像和 rails 毫无关系。之所以说毫无关系，是因为每个问题都普遍存在在其他语言和框架以及团队之中，没有一个是单属于或者集中存在于 ruby/rails 中的。

借助 rmagick 比较方便。

require 'RMagick'

class MyImage
  include Magick

  MAGIC = 257 # for 0..255 values.

  def initialize(image)
    @image = ImageList.new(image).first.quantize(number_colors = 256)
  end

  def color_of(x, y)
    color = @image.pixel_color(x, y)

    # return [R, G, B] in 0..255
    [color.red, color.green, color.blue].map { |n| n / MAGIC }
  end
end

m = MyImage.new('123.jpg')

puts m.color_of(1357, 905).inspect

测试了下大概可行。具体代码

homebrew 简直不能再方便，目录结构不能更清晰，你需要的是花几天看下文档。

xpath 查找。查找处于目标下位的同级点用 following-sibling //div[@id='xx']/following-sibling::div/text()

Kernel 不是 module? http://ruby-doc.org/core-2.3.0/Kernel.html The Kernel module is included by class Object, so its methods are available in every Ruby object.

这代码我觉得重新写个更快点。

于其多，还是精更重要。幸好 ruby 视频教程虽不多，但是质量高的有。如果是想利用视频来入门的话，我推荐两个: Ruby Essential Training. Ruby on Rails 4 Essential Training. 两者作者都是 lynda 的 kevin. 由于讲的很通俗易懂，所以印象很深，在此推荐。英语不行可以搭配中文字幕. 有了一定认识，涉及实作经验时，可以看看 railscasts.

我觉得跨平台方案是第一选择。一套代码，一种技术栈，以及基于其上的一个团队。还是能很大程度上节省成本，更快的推动产品迭代. 效果上，原生的肯定会好。不过大部分产品都活不到要求原生的时候。

1. 个人更偏好 curl (curb) 胜过 openuri
2. 示例中的 httpget 多余。
3. html_response = open(uri) { |http| http.read }, 无需预先声明 html_response, 单行 do end 改用 {}
4. !html_response[keywords].nil? 改为 html_response[keywords].present?, 如果是非 rails 环境。那改用 unless, 并且改为 guard 形式。
5. 偏好 guard 形式提早返回。如果要用 if else 先处理焦点分支。
6. httpget 和 httpgetwithassert 不够 dry, 有重复内容。可以重构下。
7. 你的方法名起的不好。http.httpget 很别扭。http.download, http.fetch, http.receive, http.send 等等会否好些？
8. 你可以把 参数 放到构造方法而不是接口方法里。

这 books 和 details 是 one <-> one 的关系吧？有必要拆开吗？合并 books 和 book_details 为一个表是否更简洁一些？如果可以合并，就无需考虑此类问题了。

哪有'纯'后端的程序员。前端总是要会的，不用成为专家，全面了解还是要的。 我个人觉得翻书虽然好，但其实效率却是最低的。因为没有实际应用，就不知其所以然，也容易顾此忘彼。最好是上几个比较大的项目，独立完成。借此学习和完善技能链。

所谓 java 写的玩意就够'工业', 就少错误，本身就是伪前提。没什么现实来支撑这个论点。国内 java 写的那些比 facebook 还是 twitter 稳定？我看未必。国外大牛写的 java 比其他语言写的更稳定更容错？也未必。 所谓稳定是建立在老东西往往可靠的错觉上吧。

偏见源于不了解，ruby 在国内属于小众语言 (http://www.oschina.net/question/58387_246846) 个人觉得偏见也源于人对于自我认同感的一种自卫行为。所以才有各种鄙视链。我觉得这种行为普遍存在，和是否科班出身好像并没有绝对因果联系。当然这是猜测，楼主得出调查结论后不妨分享下。

如果是遵守约定的话，动作同名的 view 自然会被渲染，不用手动 render. edit: 如果你要在一个动作里面渲染各种 view, 我感觉好像有点 bad code smell. 还是检查下设计比较好。

作为两个模型分开来，不要夹杂在一起。

不是这样的，比如 category has many books , 那么可以使用 category_book_path

你这种情况是不会生成 check_user_path 这种路由的. 如果只是为了避免这个错误，你可以 get /users/:id/check , to: 'users#check', as: :check_user.

没看完，记得翻译还算是不错吧. 自从看了 <>后，对于翻译质量的期待阀值大大降低了。

undefined method "length\n" 不是已经说明一切了？没有 length\n这个方法 , length\n 和 length 能是一回事吗？gets 返回的带一个\ n.

反爬总的来说算是伤敌一千自损八百的行为。除了用户体验，还有 seo 方面得考虑进去. 个人有以下几个考虑：

1. 为了 seo 方面的考量，尽量避免 javascript.
2. 随机变动 html 结构，通过随机增加空 tag, 变动上下顺序等办法，让节点路径查找不便。
3. 跟踪用户访问资源的频率和数量，可疑行为加上验证码。