• 说句题外话, 如果使用 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 包括其他框架的环境是起到 配置分组 的作用,从高层一点来理解,环境是按 使用场景 来分组的,毕竟每个场景所使用的配置项都差不多,指定一个环境名比设置多个环境变量更方便。

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

    1. 有点经验或者认真看过 Rails 文档的基本不会犯这种错误。
    2. 认真读一下报错信息也能解决问题。
    3. 就算读不懂报错信息,把错误整个 copy 一遍 google 也能搜到吧。

    不多评价。

  • 问一个数据库设计问题. at 2017年3月08日

    先不加这种额外关联,等查 log 发现慢了之后再考虑不迟。

  • 这个广告做得好 at 2017年3月04日

    脸大就是有优势

  • 是的。

  • 最后一个 INSERT 语句应该可以用 ON CONFLICT 吧,这样可以简化一点数据对比和删除的过程?

  • 赞一下 LZ 的博客,但我觉得 Goldiloader 这种 gem 还是不用为好。

    本来 N+1 就是因为开发人员疏忽,但程序聪明的做了一些事情,让问题隐藏下来了。更深入一点想,是开发者对程序失去了控制:你不确定它什么时候在干什么事情,当然容易出问题。

    Goldiloader 也是聪明的帮人做了一些事情,同样容易隐藏问题:

    1. 触发一些不必要的 includes/preload 。
    2. 如果用了一段时间之后,因为一些原因把某个关联 auto_include: false 了,也不知道哪些地方会重新触发 N+1 查询。
  • 这种思路本质是靠猜测前置任务的执行时间,影响因素太多且有潜在的时间浪费(任务失败,队列拥挤,Sidekiq 挂掉重启……)。

    更稳定的做法是用 sidekiq-status 这类记录任务状态的插件,比如把前置任务 A 的 id 全部记下来,在 B 里检查前置任务的状态,再做针对性处理,比如全部完成且正确率到 90% 就处理,否则把自己 enqueue 到 n 秒之后。这个方法也能很容易的扩展成多级的任务链。

    Sidekiq Pro 也有 batch 功能解决这类问题,我这种没钱用户没体验过。哪位有经验可以分享一下。

  • 说说我前段时间碰到的类似问题,希望对你有帮助。当时也是装第三方 apt 源不成功,不过错误类型是 apt-get update 报 403 。后来发现是阿里云的主机对 apt 配置了代理,应该是为了让内网机器访问自家的源加速,但影响了第三方源的获取。

    代理配置在 /etc/apt/apt.conf 里,把它注释掉再 update 就没问题了,注释用 # 号:

    Acquire::http::Proxy "http://mirrors.aliyun.com/";
    
  • @lgn21st 同类型数据库肯定是用 dump 工具方便。实际上 pg_dump 如果导出成 SQL 的话,也是默认生成 COPY 。跨数据库才需要一个双方都能交流的格式。

  • @lgn21st Excel 也是很蛋疼的东西 😭 @hooopo CSV 做数据库互导还是很方便的。

  • 我觉得这个需求跟 CMS 很类似,所以 LZ 可以先找一下 Ruby 社区的开源 CMS ,看看它们的实现能否有所帮助。如果自己做的话,可以找一下有没有能在运行时动态增减路由规则的 router 组件,然后 mount 进 Rails 。

  • @novtopro 并没有说这是 Rails 不能做的。Changeset 也有 ROM 在尝试,进一步放到语言层面来看,又有多少特性是一种语言完全没法实现的呢?这里只是举个例子说明下各家对同一个问题的不同处理思路。

  • 影响最大的应该是选择国内主机做跳板(比如香港阿里云)的个人或者组织。

  • 前几天 Quora 上也有讨论 Rails 是否还值得学,还引得 DHH 亲自回答。见 What makes Rails a framework worth learning in 2017?

    个人看法,高度集成的解决方案总是有市场的,默认集成了很多最佳实践,可以节省很多琐碎的决策和时间,前提是你认可框架给你的大多数解决方案。Rails 一直走的就是这条路,也总是在很积极的吸收其他好的实践,所以也不算过时。而且前端再怎么变化,其核心也是更注重展示和交互的,后端功能总得有人写吧。前端现在少有高度集成的框架,原因也很简单,各个基础组件方面都还没杀出最终的优胜者呢,还不是时候选出 “最佳实践” 的集大成者。

    不过现在其他语言的框架都吸收了 Rails 不少优点,并且也有各自的闪光点,比如我很喜欢 Laravel 单独抽了 validator 出来在 controller 那一层校验 params 的想法,更喜欢 Ecto 的 changeset 。Rails 不再是领先“友商” X 年了的选择,但对于 Rubyist 而言仍然是个好选择。这有点类似 iPhone 的现状 -- 不再是唯一的选择,但仍然是部好手机,对果粉而言更是……

  • 👍 换头像了导致我没认出来,哈哈