• 多肯定是不多,快乐倒是很快乐

  • null at March 19, 2023

    作为一个隔壁的 Elixirist 表示这种语法很 Ruby(能减则减),但清晰度不敢恭维。我现在更看重清晰,因为代码大部分时候是用来读的。

    Elixir 版本的例子,匹配都在左边。并且能明确的看到过程中的变量绑定:

    def get_user_profile(client) do
      %{id: id} = client.get_json("/current_user")
      %{nick: nick, bio: bio} = client.get_json("/profile", %{id: id})
    
      %{id: id, nick: nick, bio: bio}
    end
    

    个人感觉,如果觉得 pattern 里 %{id: id} 十分繁琐,大可学 JS 弄成 { id } 。Ruby 里面这种语法应该没有歧义。

  • 问一下,Postgres 应该没有 UUID 主键和索引的问题吧?

    另外个人感觉迁移主键没有容易的,因为涉及到外键引用,大量迁移关联数据是个挺麻烦的事儿。

  • 我现在一般用 UUID,不用数据库自增长 id 了。自增长 id 容易被猜到临近的资源和数据库实际规模。后期改分布式比较麻烦。优点就是简单和短。UUID v4 方便,但在实际使用中通常觉得太长,尤其是 URL 中使用,而且有些人会有 id 按时间排序的要求。这点应该只有 UUID v5 可以做得到,但它本质上需要开发者自己保证唯一性。

    现在互联网应用也很少看到自增长 id,而是用各种字符 id。实际项目中对 ID 一般考虑几点:

    1. 是否需要前后端都可以生成
    2. 是否需要异构的微服务都方便生成
    3. 是否需要中心化的 ID 生成服务,还是每个服务可以自己生成(只要遵循统一的算法)

    如果考虑 1,那么只能考虑 JS 也能生成的方式,比如 UUID v4 / NanoID / Hashids 都行。如果考虑 2,那么需要一个有多种主流语言实现的方式,或者雪花算法。这个思路其实很值得学习,基本上是分布式 ID 的通用套路了。另外 MongoDB 的 ID 生成方式也可以考虑。

    贴一个 Instagram 的分布式 ID 生成思路。能做到 Postgres 里去,保持数据库生成 ID 的同时效率不低。

  • 喝啥无所谓,关键是喝的时候觉得文思泉涌

    然后第二天早上起来把代码删了重写

  • 这就是回表的。因为你有大量索引外的字段。如果只查索引的叫 index only scan。

    其实是不是回表无所谓。因为业务拼装的 SQL 可能性很多。一般建立索引是快速缩小范围,然后再回表查。你可以用“哪些字段能让你快速过滤掉大量无关数据”的原则来建立索引。

  • 图(yishan) at June 26, 2022

    人在上海或武汉吗?可以加我微信聊聊 (darkbaby123)

  • 呃,团队现在还没到搞办公室政治的规模,等人员多到能拉两个或以上的政党起来,我们再认真研究这个事情……

  • 描述事实而已,这个词成反义词了?

  • 公司也在考虑,可以先聊聊,你加我微信?

  • 是的,上海如果有合适的也招

  • 一张图了解 Elixir Ecto at April 29, 2021

    用是当然用的。只是 Jose 提了一些 更严格的理念 。这些道理放在任何语言都是相通的。

  • 看了这我才知道国外政治正确真不是 B 站玩梗性质的。不过看 原博客 我觉得 Basecamp 做得对,里面说的改变有助于简化组织结构和降低沟通障碍。Jason 提了很多“我们曾经就是 xxx,但后来变成 xxx”这种句式,感觉还是想回到最初那种简单的状态。

  • explain 的结果不准吧…… 本质上它是 PostgreSQL 为表存储的一套大概统计数据,用来决定 query plan 的。不过这脑洞确实大。

  • 首先我没用过 GraphQL 😂 ,但我们团队用过一点点。GraphQL 无法取代 REST,除了它自己有些缺点之外,我觉得还有个原因:它的目标是前端友好,但需要后端买单。相比一个功能完备的 REST API,GraphQL 并没有省多少开发成本。

    GraphQL 相对 REST 最大的优点,是一个思考细致涵盖了通用需求的标准,而且因为它受众挺广,各种实现库也很多,不用自己造轮子。但它有些问题是设计决定的,比如前端请求时需要描绘数据的形状,如果前端无法确定数据的形状就很无力(多态或嵌套层级不定的数据);比如前端对某个资源本来就要获取全部的属性,此时 query 严格定义属性的负担大于好处。

    REST 只能算是一种设计风格,具体到复杂的查询,关联数据这些,每个公司都有一套自己的做法(而且不完美)。虽然有一些散乱的 RFC,但都说不上大众标准。更别提库的支持了。但从另一个方面来看,无标准的好处是灵活,你可以结合需求定制适合自己的标准,并且按需添加功能。因为 REST 不强制你必须达到某个最低标准。

    REST 对前端的的缺点是太自由了导致没有合适的库。自己写 HTTP 请求,构造数据,解析返回这些都是很重复的事情。要做个通用的 API client 也不是不行,但首先需要定义一个严格的标准。拿返回值解析来说,如果要用一套代码解析出不同类型的数据和关联,那么首先数据结构需要包含资源的类型,哪些属性只是属性,哪些属性是关联,关联的类型是什么……

    至于节省数据流量之类的,一般产品上规模的公司才需要操心这些问题。而且嵌套数据无法避免重复 -- 10 个 post 的 author 其实只有 3 人,这种用嵌套就是 10 个 author,把数据拍扁了放在顶层反而更节约。

  • 哦,我知道了。看到备注只有“我是 XX”所以我没加…… 我来加你

  • 你好,是 Ren** 吗?已加

  • 什么叫本质?你自己去试试就知道了。

  • 一种假的 API server,可以通过一些预先编写的规则生成 REST API,这个在前后端约定好接口但还没有具体实现时比较有用。你可以找一些对应的类库,或者用 Postman 和 Swagger 等工具来生成,又或者用 Apiary 这种服务。

  • 想先定义和试用 API 的话,找个 mock server,别这么野路子……

  • 这不是我想表达的重点…… 其实都是两种语言里的不同特性,放一起比较也没什么意义。想了解你可以看看 Elixir。

  • 只拿 Elixir 举例,我个人是觉得函数式的写法更灵活点,最主要的原因是函数不用绑定 this ,所以数据和行为(函数)可以更自由的组合。这也是跟 OO 最大的差别。代价就是因为每次数据和行为组合都要严格指定,代码必然会更多,所谓的更 explicit,比如 user.save()Repo.insert(user)

    比如有时会碰到“一个数据在不同的业务场景下有不同的关注点” ,在 Rails 里就代表一个 model 有多种不同的功能,它们可以用 concern 实现并混入这个 model,这是一种 mixin 的方式。另一种方式是用 ContextA.do_something(some_model) 的方式来处理,把每个业务场景下的逻辑放在自己的模块里。函数式基本就强制你使用后者了。更复杂的逻辑可能涉及多个函数调用,就可以用 pipe 描述成 params |> ContextA.get_model() |> ContextB.calculate() 这种方式,简化一下函数嵌套。

    为什么说链式调用没有 pipe 灵活?因为 obj.do_something 的前置条件就是这个方法必须归属于调用者对象,有时这是一种限制,导致必须用继承或 mixin 来组织代码以达到复用的目的。所有链式调用都可以写成 pipe 的方式,反过来未必成立。

  • @zzz6519003 @Rei 如果是这样,那确实没有用。反而怎么写都没有 . 简单。从语言层面来说我觉得 Ruby 也没必要关注“给现有功能多一种表达方法”的事情,这就不是语言设计者该做的事情。

    @jasl Lisp 据我对 Emacs Lisp 有限的了解,它允许 variable 和 function 用同一个名字,比如变量和方法都叫 foo ,执行再会根据使用场景辨别到底是哪一种。这大概是 Matz 说它们不属于同一个 namespace 的意思。不过这跟 Ruby 有什么关系,以及为什么会影响这个 issue 就不知道了。

  • 语法不管怎么改,含义还是类似 Elixir 的 pipe,把上一个操作的返回值变成下一个操作的某个参数,让代码组合变得更容易。有些场景下 pipe 比链式调用泛用性更高。链式调用的缺点之一是必须把函数混入进某个 object,导致 object 承载多个部分的功能然后变得臃肿。

  • 一开始会,后来…………后来你就习惯了

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

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

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

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

  • 关于 URL 规范 at January 11, 2019

    首先我更支持平级非嵌套的资源表示方式,即 /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 January 05, 2019

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