• {}do ... end 的区别只在于跟前面的方法结合的优先级,简单来说 {} 会 “紧贴” 它前面的方法,而 do ... end 更加宽松。

    我看楼主之前有过几个帖子讨论语言的设计优劣问题。但说实话纠结这些并没有太多意义,更多是结合个人偏好的主观问题。倒不如多了解下各种语法的客观差异,避免踩坑,然后总结出一套符合自己偏好的编程方式和风格干活。

  • SQL Style Guide at 2018年09月10日

    确实 query plan 不同,感觉 CTE 更严格的按照每一步去划分优化的边界,而子查询作为一个整体查询有时候会优化得更多一点。所以我一般是测试时写 CTE 然后转到代码里再换成子查询。这样也更容易转换成 app 层的代码。因为 Elixir 的 Ecto 可以写出非常复杂的分析型查询,但目前还不支持 CTE 。

    Emacs 有个插件能帮你对齐,也是你说的 river 风格。不过 Emacs 的对齐功能基本都有点自恋 + 死不认错,人工调整后编辑器也会不停的帮你 “纠正” 过来。想调整规则得去研究类似 AST 的数据结构,所以我直接放弃了……

  • SQL Style Guide at 2018年09月09日

    缩进方式很有意思。这个例子还是很考究的,比如 JOIN 其实是属于 FROM clause 的部分,算是 FROM 下一层的表达式,因此缩进在 FROM 的更右边,ON 下面换行的 AND 同理。

    这种方式我尝试过一段时间(可能不是严格照着这个 styleguide 来的)。最大的感受是必须有编辑器提供自动格式化才好用,几乎没办法靠人工维护。尤其是写超过 20 行的话自己都不知道缩进对不对,每多加一行都可能导致之前写的部分重新缩进。

    PostgreSQL 文档里有些 SQL 例子是按这种方式缩进的,但也有混用的。比如 window function 的一个例子,内层按分界缩进外层就顶头了:

    SELECT depname, empno, salary, enroll_date
    FROM
      (SELECT depname, empno, salary, enroll_date,
              rank() OVER (PARTITION BY depname ORDER BY salary DESC, empno) AS pos
         FROM empsalary
      ) AS ss
    WHERE pos < 3;
    
  • Why Sometimes I Write WET Code at 2018年09月08日

    DRY 的代码特点是 “改了一个地方,所有相关的地方都被影响” 。有时候这是好事,另一些时候则是坏事。我觉得用 reason to change 来衡量代码是否需要可重用是个可行的做法。如果两段代码实现相同,但是为了不同的业务目的,那就让它重复。

    另外也赞同接口设计比实现更重要。接口定义得良好,实现烂一点影响范围也有限,并且容易重构过来。个人感觉过度重视局部代码的精巧结构,以 DRY 为主要的衡量指标,甚至以实现来反过来影响接口设计是很多新手常犯的错误。

  • @chenge ROM 里借鉴了 Changeset 的概念 :https://api.rom-rb.org/rom/ROM/Changeset.html

    Rails 的 ActiveRecord 作为一个超级 model ,在框架层面集成好用的功能于一身。这点跟 Ecto 在设计理念上有根本差异,脱离这点谈 Changeset 不大现实。毕竟 Changeset 的所有功能在 AR 里都有,只是如何组织,以及好不好用的问题。无端添加一个概念反而容易让人迷惑 -- 我该用那种方式修改数据?这点在 Ecto 里并不存在,因为 Changeset 是唯一修改 “模型” 数据的方式。

    Changeset 另一个好处是容易脱离数据模型再开一层抽象,比如做外部数据的校验。这方面其实 Ruby 也早就探索过,不过是叫做 Form Object 。虽然 ActiveModel 不太给力,但 Ruby 社区的轮子也不少,不喜欢 AR 的可以去用 dry-rb ,有相对完善的校验和类型系统,足够你干很多事情。

    名词是新名词,但内部概念还真不是新概念。

  • Elixir 的一些想法 at 2018年09月04日

    @chenge 建议从 Ecto + PostgreSQL 搭配入手。Ecto 对它的支持最好。

  • 求一条 sql 解决分组问题 at 2018年09月04日

    没看懂你要的计算逻辑,好歹也表达清楚点吧?

  • 嗯,就是延迟反序列化的过程,这里的 pg 也是说的 Ruby 库,跟 PostgreSQL 本身没什么关系。

    PG::Result stores values received from the database internally in a compact memory format. When the value is accessed, it is converted to a ruby string or casted to another ruby object.

  • Ruby 对 csv 文件进行统计 at 2018年08月04日

    不考虑数据量问题的话,就一个简单的 reduce :

    require 'csv'
    
    CSV.foreach("data.csv", headers: true).reduce({}) do |acc, row|
      priority = row["优先级"]
      acc[priority] = (acc[priority] || 0) + 1
      acc
    end
    

    如果量大并且需要跟其他表结合做统计,导入数据库是更合适的选择。除了用 COPYForeign Data Wrapper 也可以考虑,简单粗暴。

  • 老实说,不会。原因几点:

    1. 越是受众面不广的技术越要跟国外的一手资料。一般来说订阅 Elixir Radar 并定期逛逛 Elixir Forum 足矣。而且像 @Rei 所说 周边的书也已经不少了。

    2. 国内资料太少,考虑到实效性就更少了。因此我一般不会选择看中文的(即使搜索到)。我想近几年愿意吃螃蟹学习 Elixir 的人大多也是这个习惯。所以中文资料就更难有市场。这确实是个恶性循环,但任何圈子的形成都是需要时间的。大部分时候我们是要解决问题,那就得用更有效率的获取知识的方式。