• 编辑器的发展趋势? at March 09, 2024

    如果是特指文本編輯器,我覺得就是強化 LSP 之類的東西,讓他們支持更強的重構功能。如果包括非文本編輯器,那麼結構編輯器更先進,雖然我覺得還是文本操作起來舒服。還有別的輸入方式如 不用鼠標鍵盤,用 eye tracker 和語音輸入編程

    不過我感覺效率不會很高,但是這個基礎上可以加 AI 改進

  • Object Shapes 浅析 at February 28, 2024
  • 一直有搭個自有的聊天室的想法,考察過 matrix 總感覺設計和實現都很混亂,該試試 campfire 了

  • null at November 04, 2023

    opal 理論上是能用的,但用到 js 庫都要寫個 binding,性能也會比正常 js 慢,有不少人嘗試過做 opal 的組件框架,如 hyperstack 和 clearwater,不過目前看都是棄坑的狀態,現在前端都 ts 和 vite 了,opal 做點簡單的可能還行,不然開發體驗跟不上

  • 用自己的編程語言寫軟件好酷

  • 再见啦,Ruby on Rails at September 07, 2023

    omakase 的副作用,還好我完全沒想法碰 rails 團隊的前端方案…

  • 沒事,我很理解你的想法,因為我以前也覺得什麼都應該用 ruby 來做,不過對於沒有深入了解 oo 和消息傳遞這套機制的人來說,ruby 對他們並沒有很天然的吸引力,我想給數學朋友安利的時候也無法說清這比起他們現有的工具究竟有什麼優勢?但是對於業務程序員來說,ruby 的優勢是很明顯的,例如 rspec 就沒發現哪個語言有功能相當的替代品,這也是我對 ruby 依舊有信心的原因

  • 我說的不是調用,是傳遞,ruby 的語法是對單個 block 優化的,這導致寫 dsl 很好看,但是如果需要傳入多個 block 就會要轉 lambda,其他語言沒有 block 的設計,但是 function 可以當第一公民傳遞,例如 js 裏function a(){} 之後 a 本身就能傳給其他函數,而 ruby 需要先method(:a)轉成對象再傳

  • 不需要宏,ruby 本身就有 callcc https://ruby-doc.org/core-3.0.0/Continuation.html ,當然你要宏也是可以的,我指的是先 parse 再改 ast 的宏

  • python 的 def 定義的是 function,ruby 的 def 定義的是 method,method 要轉換成 object 才能被傳遞,別的語言的 function 隨意可以接受兩個 function 作為參數,ruby 卻只能帶一個 block,這本來就是設計 tradeoff。你提別的語言倒是提對了,這個領域就算沒有 python,輪 matlab 輪 julia 也輪不到 ruby

  • 你找個用 lambda 來組織代碼而不是 def+block 的 ruby 項目給我看看?我還真想看看這麼寫多有吸引力

  • 沒覺得[]哪裏自然了,你要是覺得這個好用那你就把一切代碼都用 lambda 和 [] 寫好了,除了以前玩邱奇數我就沒見過誰這麼寫 ruby,而且要這麼寫我為什麼不用 python?ruby 真正有意義的構件都用不上。每一種抽象都有各自的長短處,如果你認為 ruby 選擇的抽象就是終極銀彈,我只能祝你好運。

  • 你要反駁我可以 at 我的,ruby 只有 method 沒有 function 我覺得應該是 rubyist 的常識,function 的特徵是可以做 composition,但是 method 必須要轉換成 callable object 才能做 composition。callable object 在 ruby 裏是做不到 python 的 function 那麼自然的,會弄到到處都是.call或者.()

    https://thoughtbot.com/blog/proc-composition-in-ruby 供參考

  • python 是多範式語言,ruby 是 oo 語言,天生沒有函數,對數學的親和力差

  • 操作符在參數列表和在函數體裏意義不同應該是 c 以來的傳統藝能,c 的*在參數就是聲明指針,在函數體就是取值,同理 ruby 的&在參數裏是聲明 block,在函數體是轉換成 block

  • @316786359 @lijunwei 谢谢,我大概能理解这两种测试的区别,不过一个问题是集成测试应该怎么写,如果单元测试已经覆盖了对内的所有东西,那么集成测试只应该测试不同单元之间的调用,也就是如果 A 单元调用了 B,只要确保 A 发出了调用的信息,并且调用信息和 B 单测里期望的调用结构是一致的,别的什么都不需要关心。这样的话单元测试和集成测试覆盖的东西才没有交集,如果能做到这样应该是很好的。

    我的案例应该不适用单元测试和集成测试“覆盖面”的差异,举个例子,一个测试是写关于顾客购买了的商品,那么在准备测试数据的时候,自然的想法是PurchaseService.call(client, product),然后数据库里就有这个用户买完东西的状态了。但是我同事会说,这里不应该调用 PurchaseService 因为它创建的东西不完全是测试需要的,应该用 factory 自己构造一个购买后的状态。那么在这里用 service 还是用 factory 构造测试数据其实和覆盖面是没关系的,用两种方式该覆盖的都不会少。我认为如果以测试全部跑通为基准,显然用 service 能发现比用 factory 更多的问题,因为如果 factory 都会挂那么 service 也一定会挂,但是反之不然,用 service 挂了可能是 service 的问题,用 factory 是不会挂的。如果以测试跑通的比例为基准,那么用 factory 是更好的,因为有相当一部分测试可能不会挂了,但是这是以维护多一套 factory 为代价的,而且实际上挂的事实没有改变。因此我觉得“隔离测试以保护其不挂/不变”意义不大,可能对于足够大的项目,测试跑通的比例对于他们的规划/定位问题是有意义的,但是对于我们的小项目就没意义了。这里可能有一种容错和速错的理念区别

  • 看起来不错,这个应该可以参考,不过我需要的更多是关于数据库的数据,例如一些测试用例的数据需要一串 service class 调用才能生成(用户做了什么操作),和 service 的耦合是在这里引入的。我需要把这些操作的数据库结果集存起来(相当于 factory),然后在跑测试之前重放,如何进行 diff 可能也是个问题

  • 我的做法是新开了个类似 routes 的文件夹,然后里面定义 endpoints 的 dsl,然后在 routes.rb 里面读取和引入这些 endpoints 定义成实际的 routes。然后这些 routes 都是按约定对应到 controllers 上的。

    然后再用 rails 的 FileUpdateWatcher 监视这个目录的变化,然后当有变化的时候触发 routes reload,就可以实时更新,别的类型定义等都存成类文件,要用的时候按名字 constantize,这样可以利用 rails 的 autoload。

    这样的话实际上对 rails 的侵入部分就只是 routes,做成插件应该不难,难的是确定各种约定,以满足不同用户的需求

  • 因为这个 dsl 是我自己写的,ts 生成也有了,目前用起来还是很爽的,后端加上检查之后返回类型不吻合的数据会抛错,这样前端可以保证不会遇到类型错误了😃

  • 这就是团队内斗的一部分,急需高限制性的手段来规范他人的写法,所以我引入了 typescript vue3 还有一系列规范,防止他们继续用 vue2 堆屎

  • 我觉得传统 restful 和 graphql 的区别也没有那么大,因为标准的 restful 任何东西都要抽象成资源,就算是订单取消都要"POST /orders/:id/cancellations",这里面的cancellation不一定就是真的对应模型,可能只是order的一个字段,后端暴露的资源完全可以是虚构的

  • 看到了那个 apollo codegen,确实可以实现生成 ts,这个应该更适合普遍使用,我的就在自己项目里瞎玩就好了😂

  • 对,这个过程可以省掉,甚至连协调 url 的过程都可以省掉,但更重要的是要在前端用 ts,不生成的话需要自己用 ts 写一套类型,然后假定拿到的 json 一定是符合前端类型的,数据的字段啊类型都可能出错,降低效率

  • 我不太熟悉 graphql 的生态,可能我这其他人 adopt 它很难(可能也包括我自己),不过思路可能有接近的地方。这个应该更接近 rpc,如果前端后端都是 ts,那https://trpc.io/ 这个会非常爽,但估计对于 rails 能生成一套前端函数已经不错了

  • “At 00:00 on every 3rd day-of-month if it's on Sunday in September.”不是写的很清楚吗,依赖了周日,不要周日的话把最后一个改星号

    另外一楼的工具和 crontab.guru 的结果不一样,我更信 crontab.guru 的

  • 👍 我以前觉得 ECS 是 OO 发展的终极形式,因为 OO 仅考虑了对象有什么属性,ECS 还考虑了视角的问题,即同一份属性在不同人看来是怎么样的

  • nil at June 15, 2022

    这些称作计算器语言更恰当,定理证明器是什么样的可以参见 https://ruby-china.org/topics/41265 或者 https://leanprover.github.io/

  • nil at June 15, 2022

    现实中的例子就是把数学证明写成代码,然后用计算机验证。定理证明器只能通过搜索来找证明,搜索空间不会太大,因此自动并不是重点,重点只是验证。

  • nil at June 14, 2022

    数学非常关心数据类型,类型决定了性质,同样一个数字 1,在 mod 5 和 mod 6 的意义上是不同的,前者是域可以套用线性代数,后者就不行。所以数学里取一个数字都会写 let n ∈ N,let n ∈ Q 等等,这些就是数据类型。数学的未来反而是迁移到由更强大的类型系统支持的定理证明器上,这样才能用机器验证证明,并且构造一个可靠的数学知识库。

  • 支持,代码用粤语读起身好过瘾