• 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 的现状 -- 不再是唯一的选择,但仍然是部好手机,对果粉而言更是……

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

  • #67楼 @jimrokliu 是的,Supervisor 是 OTP 内建的行为之一,经历了这么多年足够稳健。类似的机制其他语言并不是不能做,不过稳定性这东西是需要时间积累的。

  • 圣诞礼物:Ruby 2.4.0 Released at 2016年12月25日

    每年圣诞有惊喜

  • 思路还是 GraphQL 那一套,那我更宁愿去试试 GraphQL/Falcor 。而且它的简单基于一个假设:JSON resource 结构跟数据库的表结构一致。现实中稍微复杂点的模型都不是这样的。所以 -- 不怎么看好。只说说我还算了解的 JSON API 和 GraphQL 。

    JSON API 适合粗粒度场景,是 REST 思路的延伸,各方面都有所考虑,对处理 relationship 有自己的一套解法。如果自己定义 API 规范有些想不清楚的地方,这个规范值得参考,但不见得值得使用。不过如果非要在同类规范(HAL, Siren 等)中选一个,我更愿意选择它。最后,如果使用 Ember + Ember Data 的话,这个规范还是推荐的。

    GraphQL 没实际写过,感觉适合细粒度场景,适合前端频繁变化的应用,配合 Relay 和 React 可以有效的整合各个组件中的请求。我个人更喜欢这种方式的数据层,屏蔽了发起哪些查询和何时发起查询等细节。

    最后,写 API 本来就是个体力活,这部分本该自动化一点。

  • 果然大部分是 Ruby 转过去的,不过 Erlang 人群居然很少。

  • Leftover 的编程语言漫画 at 2016年12月18日

    上周刚看过,另外 The difference between Java and JavaScript 也很搞人。左箭头翻页就是。

  • #10楼 @chenge 这个别问我,我真的不知道,而且最近也没有学图理论和相关算法的计划。

  • #7楼 @chenge 没有,这属于图理论的,我一点都没学过。你感兴趣的话还是查 wiki 吧,理论搞懂了应该不麻烦。

    #8楼 @nightire 有空写点 Elixir kata 练练?