• 说句题外话, 如果使用 PostgreSQL 的话,查询 tree 结构的 children/ancestors 都可以用 WITH (CTE) 做递归查询,稍微封装一下就可以不依赖任何库。详细信息可以看 文档

    优点:

    1. 单条 SQL 查多级父子关系,而且不用缓存都很高效。
    2. 不需要额外的字段,只需要 parent_id

    缺点:

    1. SQL 查出来的结果始终是平铺的记录,如果需要树形结构的数据,得在应用层面做转换。不过平铺的数据在某些特定场景下(比如 JSON API 规范的 compound documents ,或者其他展平关联数据的 API 格式)反而是优点。
    2. 上一点提到在应用层面做转换,但对 ActiveRecord 而言不太好做,因为 model.relationship = another_model 会引发一些副作用,如果是转成纯 Ruby 对象就不存在这种问题。
  • 北京面试所感 at 2017年4月14日

    面试是很难看出一个人的真实能力的,所以很多公司不得不采取一些能够量化的标准:工作年限,过往履历,毕业院校…… 包括算法水平和笔试题其实也是量化的一部分,目的是最大程度的刷掉一批人,让有限的人力能投入到公司认为合格的人身上去。这跟吐槽了很多年的高考有点相似之处 -- 不是一个好的筛选方式,但至少是个简单易行也勉强可用的方式。

    LZ 不妨思考一下如何量化自己的优势和公司的需求。前者了解自己,后者了解对方。多了解一下面试公司的要求,甚至是多个公司对你想要的职位的平均要求,然后针对性的弥补。即使面试失败也可以多问对方一些问题,比如理论知识不足说的是哪些理论知识?需要如何补充?能够量化的东西就有优化的空间,不然努力不到点子上,就浪费时间精力了。

    最后,12 个星期拿来练手,真不如找个公司做事。别以学习的名义逃避求职,这才第三次呢。

  • 偶尔关注下 Crystal ,不过还是更看好 Elixir 多一些。个人感受是单纯的函数式编程并没有跟传统的 OO 有非常大的差别,相反很多理念是可以通用的。造成 Elixir 最大思维差异的是 process 的设计,以及衍生出来的 OTP 的那些东西,这都是 Erlang 特有的思路,函数式编程语言中貌似也就此一家。

    喜欢 Elixir 的一个主要原因是,它是一个考虑到应用层级的解决方案,而不仅仅是提供一个语言。Mix 提供完整的项目构建和管理,ExUnit 提供完备的测试框架,Application 提供的组件化单元,Supervisor 提供的监控和重启机制(后两者都是 OTP 的范畴了),release 提供的打包和热更新…… 虽说 Elixir 很新,但得益于 Erlang 三十年的发展,各种基础组件都还比较稳固。不像其他语言要从地基开始重新做起。我觉得大多数基础设施还是需要时间积累的。

  • 我好半天才想到 “返工与遥遥” 是 Rework 和 Remote 😄

  • @nightire 应该没问题的。这跟你说的 npm link 其他 module 是一个意思。不过不重启 server 就更新代码我记得只有 Rails engine 才行。

  • gem 以 git submodule 的方式放在你的项目下,然后用 path 引用:

    gem "your_lib", path: "./vendor/your_lib"
    

    版本的话,用 git 管理比强制每次 bundle install 自动更新要更靠谱点。

    http://bundler.io/v1.5/gemfile.html

  • includes 加条件也许可以:

    Post.includes(:comments).where('comments.user_id = ?', current_user.id).references(:comments)
    

    参见 Rails 文档

  • JavaScript 和 Elixir 。Ruby 用的不多……

  • up 主在此 @nightire

  • Rails 包括其他框架的环境是起到 配置分组 的作用,从高层一点来理解,环境是按 使用场景 来分组的,毕竟每个场景所使用的配置项都差不多,指定一个环境名比设置多个环境变量更方便。

    少数情况下会出现同类型的使用场景需要不同的配置项,最典型的是数据库等外部服务的配置。这个时候把少数配置抽成环境变量更加灵活。