#1 楼 @w7938940 最常用不应该是 each 吗

太赞！

来支持楼主，全栈译者！

#12 楼 @seabornlee 哈哈，不用解决了，要装作有很多内容的感觉

#10 楼 @lionzixuanyuan 这个问题在 Ruby China 本身也有的

#6 楼 @leondu 初始版本已经死在路上了，感谢 Beansmile 接力造福社区 #7 楼 @rubyist518 哈哈，这个涉及 PDF 的解析了，理论上可行

赞！

此题适合邀请 @leondu 来分享。

#3 楼 @peter 你说的是运营吧？

#4 楼 @hemengzhi88 最后补充一句，我说的每一个技能，我都不敢自称精湛，连熟练我都不敢说，只是思考！只是思考！只是思考！

#4 楼 @hemengzhi88 #15 楼 @rudy #18 楼 @nightire 上次回复完了就没有再回来看过了，一下子这么多讨论着实意外。可能是我表达有问题，但是感谢 @nightire 的理解与补充说明。我知道我说的那些问题对一个应届生是很苛刻，但是我想表达的是，我并不是真的要求楼主能做到这些，但是我希望楼主能够主动发散思考，举一反三。但你在学一个技术，用一个技术的时候，你要有一种渴望，渴望去了解底层的实现，渴望了解是否有类似的技术，渴望了解不同技术之间的优缺点，渴望去跟别人分享这种技术，不去积极主动地思考，你就永远只是一个文档的阅读者，你会用这个技术，但是你不知道为什么可以这么用？当你开始思考并且发现更多未知领域之后，你就会发现自己的时间更加不够用了，这是最幸福的感受。

我之所以这么强烈建议，是因为我自己就从这种方式中成长过来。当我用着 jQuery 的时候，我非常好奇为什么全局的 jQuery 函数既可以接收一个匿名函数，又可以接收一个 css 选择器，也好奇为什么当参数是匿名函数时，就相当于一个 jQuery(document).ready(function(){...}) ，既然是 css 选择器，那 jQuery 拿到 css 选择器之后又是怎么工作的呢？还有一大堆 $.fn.bind，$.fn.on，$.fn.delegate 函数又是什么鬼？好像都差不多？带着这些疑问，我去阅读 jQuery 的源码，继而从 jQuery 的底层实现中发现：

1. 选择器底层： document.querySelector，发现 SizzleJS，所以当我需要处理 DOM 时，如果是轻量级项目，我不再引入 jQuery，我觉得内置的 document.querySelector 以及 document.querySelectorAll 已经够用，而且简单快速；
2. $.fn 只是 jQuery 对象的原型，所有插件的机制其实只是扩展了 $.fn 对象，所以写插件变得如此简单，只要了解原型继承基本就够了；
3. jQuery 中的 $.fn.on 和 $.fn.bind 和 $.fn.click 之类的方法，其实都是相互之间的别名或者快捷封装，从此就可以自由游走在不同方法选择中了，另外，我在自己的 js 代码中也尝试将代码解耦写成插件，提高复用，很多时候也会模拟 jQuery 的这些方法别名或者封装的技巧。

如果我只是认为我只需要知道如何使用 jQuery 就够了，那我肯定不会去主动研究这些东西，同样我也可以完成工作，只不过，在研究一番之后，我觉得我能够学习到 jQuery 源码的一些技巧，然后应用到我自己的代码上，同样完成了工作，但是我觉得更优雅了而已。我认为工程师的基本素养不能仅限于完成工作，而是要更好地完成工作。

很多东西现在你不知道都不要紧，但是要有自己的方向，有自己的渴望，我之前提到的，就是希望你能表达这方面的思考，而不是仅仅一堆名词的罗列。

可以列举的例子肯定还有很多很多，还要上班，就不方便多写了，祝愿楼主早日找到实习工作！我也是新手，要学的很多，一起进步！

才疏学浅，仅供参考，欢迎社区兄弟多斧正！

说了这些，跟没说差不了多少，怎么吸引人？感觉跟罗列了学过的课程一样。别人不关心你知道些甚么，别人只关心你通过你知道的这些都做了些甚么出来？你知道 Github，那你知道 git 吗？那你的 git 操作是通过命令行还是 GUI？你对 git 的工作流知道多少？你如何处理代码冲突？了解 jQuery，那了解 JavaScript 原型继承么？有没有自己尝试在项目中为了满足需求，开发简单的 jQuery 插件？你在学习这些技术中，有没有笔记之类的，可以展示你的学习能力的？建议楼主重新思考一下，如果自己是招人的，你是不是最想知道对方有多少潜力能够解决你手上的需求？要证明你有潜力，不是仅仅罗列你知道哪些东西就行了的。

#2 楼 @ericguo golang 版本应该只是楼主的轮子，现在 Dashing 还是 Sinatra 的，看了 demo，感觉挺不错的，回头研究下

#14 楼 @seabornlee 还在公司。。。

喜欢「当面沟通」多过「文档」

不知道 11 楼是如何理解的，我没从这句话里看出来任何反对文档的意思。我喜欢吃肉多过吃米饭，不代表我反对吃米饭啊。我的看法是文档是非常必要的，但是千万别让文档变为工作负担。必要的文档可以减少不必要的沟通，比如同一个事情，不同的人要反复问你之类的。但是不要事事依赖文档，很多事情，比如需求，当面沟通会比等你写进文档，然后我去看文档来得高效。

帮你 @ 公众号开发大师 @ruby_sky

看一下你的 Gemfile，有没有声明 :path

路过过来支持下

顶一个！小波是不错的技术社区贡献者！

#16 楼 @hlcfan 是的，不过我觉得可以加多一个 option 进行扩展，获得灵活性，默认不拒绝 nil，这样也不影响原有代码。

#8 楼 @yue 第二点提到的两个索引工具请先忽略，太重，而且都是 Java 系，安装运行略麻烦，可能也不一定适合，我主要是用在一些复杂搜索以及索引，没仔细研究过是否符合你的需求。

终于拜读完了，条理比较清晰，不过觉得有几点或许可以成为建议。

1. 统计功能其实最容易遇到的就是性能问题，我看你实现统计的代码是每次都从数据库查过去七天的记录，然后再 group by，这块可以建议用一个定时任务每天 0 点之后去统计前一天的数据，最后再把统计结果写到数据库，后边业务上只需要查统计好后的 PV UV 数据就好了，这种方式适合需求比较固定的场景，比如每天都想看过去的 PV, UV, 而且这些数据本来就是静态数据，适合先统计好，原始数据仅作统计结果校验。另一个不建议每次查看的时候去查原始数据的原因是，当你的数据量开始多了之后（几百万甚至几千万），这样的查询可能会明显慢下来。
2. 看你的描述，如果 Impression 只是用 varchar 存 hash 的话，这样必然没法索引，那这样 impression 其实没太大必要，毕竟这些东西我自己也可以写一个 concern，然后专门提取这些信息然后一股脑塞进数据库就行了。但是这样的话，以后如果需要做一些数据分析的时候就会非常痛苦了，比如哪天运营找你说：“嘿，帮我看看昨天有多少 PV 或者 UV 是从 xx 推广过来的，还有这些里边有多少转化成为新用户”，然后可能过多几天，运营又会找你说：“帮我看看昨天有多少来自广州的用户”。这些场景下，可能结合一些索引工具会更好，比如 Elastic Search、Solr 这些，不过这样又会增加复杂度。或许像你说的 Postgresql 会是更好的选择，又或者 NoSQL 数据库，anyway，只是一个设想，我自己也没实践过。
3. 你的那些 PV UV 数据或许用图表展示会更直观生动。

哈哈，说得一般，求轻拍。

先收藏再看，太晚了，得先睡觉了，明天再拜读

#12 楼 @jimxl 嗯嗯，是的，主要还是不想写入 nil，至于 nil 出现，那是后面场景需要解决的。

#8 楼 @jimxl 你的意思是，与其静默地照样返回 nil，还不如直接抛出异常，然后由调用方去处理异常？比如：

# active_support
def save_block_result_to_cache(name, options)
  result = instrument(:generate, name, options) do |payload|
    yield(name)
  end

  if result.nil? && !options[:allow_nil]    # :allow_nil is true default to be compatible with original behaviour
    raise ActiveSupport::Cache::NilError
  end

  write(name, result, options)

  result
end

# 调用者
def read_external_service(params)
  # allow_nil: false will force active_support to raise an error when the block return nil
  Rails.cache.fetch 'example_cache_key_here', expires_in: 7.days, allow_nil: false do
    response = HTTParty.get 'https://example.com/example/request/path'
    JSON.parse(response.body)["data"]
  end
rescue ActiveSupport::Cache::NilError => e
  handler_for_nil_cases(params)
end

#5 楼 @billy 哈哈，懒癌发作，还没提交代码，因为还要加上测试，所以看看周末再弄了

#3 楼 @jimxl 实际上还是会有异常，因为还是照样返回 nil，只是没有写入缓存而已。

#1 楼 @yukang 哈哈，好的