@cifery 好呀，你争取写一篇 放出来。

mark，有空看一下。

:plus1:

@davidqhr 你才是我心目中的大神!!

@robertyu 到时候一起去呀...

+1

我觉得 他们的想法 还是蛮不错的，特别 企业可以更直观的 看出一个应聘者的 特长了。

当然可能现在 还是不够完善，不过我相信 还是有 进步的空间的。

我觉得他们主要 分析的是 github 的代码。

期待

@leekelby 将这个 generator 封装到一个 gem 的目的，可以在多个项目里面使用，而不用写重复的代码了。 仅此而已，当然 按照http://guides.rubyonrails.org/generators.html 上介绍 放到 lib 下面，也没有问题， 就是不太方面复用而已。

@leekelby 如果想 自定义一些流程，比如我针对 gem showbuidler 写一套 generator，这个时候就可以将对应的 templates 写在 showbuilder/templates 中，类似 slim-rails 中的 generator.

恭喜楼主，北航出来的同学 很多的 nb 的哥们！！

谢谢呀@ery

@subway @rei 可以联系作者 问下能不能翻译过来 放到 selfstore 上。

好 cool

有关于他的 相关视频不？

mark 一下

预先 求一下现场视频。

发现大家 研究 这个坐标轴 都挺高的

@lgn21st 你这个 略吊

mark 先

@wcc526 public/assets/images 下面的 一些图片是为 Rails 应用程序服务，按照 Rails 的约定，这下面的文件是所有人都 能访问的。

还有一些图片是用户上传的 常放到 public/uploads/文件下。一般来说 在 Rails view 层面 控制 是否显示 就够了。如果说 用户知道图片名字可以 在浏览器 直接敲入 url 访问。

如果说 你非要控制 一些人 不管怎样 都不能访问，比如说 public/upload/vip 下面的一些文件 不能访问，那么 可以通过配置 nginx 将 请求 url 包括这个前缀的请求 转发到 Rails 应用程序 处理，然后在程序里面 控制 访问权限了。

这样做的 目的 是为了不走 Rails 应用程序，直接通过 nginx 获取资源文件，从而提高响应速度。 另外由于 assets 中存放的是 css，js，image 等一些静态文件 所以不存在安全问题。

武汉的支持一下，不过@zcpdog 按照 ruby-china 的默认约定 其实应该写一个大致的薪酬范围的。

赞，中国程序猿的未来呀

@ghosTM55 期待你的召唤 +1