• 我过去搞的不太值得学习 (Ruby) ,现在搞的更不值得学习 (Elixir) ,放弃的那个最值得学习 (JavaScript)

  • 倒着看就是最值得学习的语言排行榜?

  • 感觉就是熬夜,饮食不规律,少运动,深夜看手机,并非完全是加班的原因(虽然跟加班肯定有关系)。

    我有段时间干一白天,晚上就想熬夜看手机,因为感觉自己累了一天就这么点放松时间还不赶紧利用起来。但其实这样更累。正确的休息方式恰好不是玩手机打游戏。真正让精神放松的方式包括听音乐,冥想,出去散散步(哪怕 10 分钟),小睡一下等。当然这个意识得靠自己慢慢培养了。

  • 关于 URL 规范 at 2019年01月11日

    首先我更支持平级非嵌套的资源表示方式,即 /animals/:id ,如果要限定 zoo 下的 animals 可以用 /animals?zoo_id=1 。但在有一个唯一标识符 (ID) 的情况下就没必要嵌套了。用户访问他看不到的资源应该通过其他方式来限制。

    其次建议 LZ 多了解下 RESTful API 的定义。不是 Rails 的那套 DSL 定义出来路由的才叫 RESTful 。嵌套资源也不是所谓的标准风格。理论上只要用统一的 URL 表示资源就可以算是 RESTful 的,就算你用的是 /animals?id=1 。它是一种架构风格但不是规范。而资源有个统一的 URL 的好处是它的常规操作只用修改 method 而不是 URL + method 。并且这种统一风格可以让大多数资源受益。

    最后说一句,如何设计好的 API 跟内部怎么实现是两码事。

  • 这样递减的 sql 怎么写 at 2019年01月05日

    @wootaw 是的,如果按照 LZ 的计算过程描述,其实是有不少中间数据的,比较过程化,这并声明式的 SQL 适合表达的领域。而且如果不考虑存储因素的话化,这个需求本质上就是一个链表计算。因此把计算过程和存储分开思考,解决方案的适用性会广很多。

  • 这样递减的 sql 怎么写 at 2019年01月04日

    @wootaw 别闹 😄

  • 这样递减的 sql 怎么写 at 2019年01月02日

    翻完评论才看明白什么意思。我觉得这个计算逻辑不适合用 SQL 做,因为它的关注点并非在集合,而在集合中的每条元素。用两个链表做计算(递归比较头节点)反而更容易,计算结果再保存进数据库就行。

    如果有非常特殊的原因一定要在 SQL 里实现,可以看一下 lateral join 和 with recursive 。

  • 一招秒杀 N+1 agg 问题 at 2018年11月02日

    PG 文档上都有,见 4.2.7 Aggregate Expression

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

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

  • SQL Style Guide at 2018年09月10日

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

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