@0xsui #59 见过，想骂人，国外的 quickbooks ，API 查询直接写 SQL 。这可是国外流行的财务软件，母公司市值 1500 亿刀，

搜索
open source ppt online

找到了几个库：revealjs ，Impress.js
等，好像还带了协作功能

半年不太可能实现，web 还需要后端配合，这个也不简单。

@avastms #37 RESTful 最重要的是对业务建模，一个资源对应后端一个业务模型，所以其实是能在大部分场景使用的。只是业务模型和前端 UI 并不完全对应，所以前端的时候一般会都套上一层 BFF 。

1. 公司或者部门有规范，按照公司规范来，没有的话，公司有点问题，没做好
2. 老项目，按已有的 API 规范来
3. 新项目，看项目能不能达成一致使用 RESTful 风格的 API 设计，不能达成一致，使用 RPC 风格的 API 也不是什么问题

当然，面对说 POST 更安全，这种极其不靠谱的后端，可能及时跑路更好

我 17 年的都免费换了

@SuperMild 有了泛型更好玩一点

https://i.imgur.com/cYddxY9.png

作为后端，负责一个 admin 项目，然后收到 dependabot 的提示升级 chore(deps): bump axios from 0.21.1 to 0.21.2 的 PR ，然后 merge 了，然后页面挂了。
一脸懵逼，这兼容性也太差了。

@Joker123456789 写分布式应用的情况下，每个步骤的错误都需要仔细处理的时候就会觉得 try catch 很麻烦。go 的这种错误处理在这种场景下用起来还不错，但是写业务的时候，大部分中间步骤不需要处理，直接抛出，当然 try catch 很爽。
Result + ? 操作符，这两种情况场景处理起来的感觉都不错。

Go 的 error 对应的是 Java 的 checked exception ，和 Rust 的 Result<T, Err> 本质是一样的，只是用起来方不方便而已； Go 的 panic 对应的是 Java 的 runtime exception

@SuperMild 可以兼容已有的库，只要最后一个返回值是 error ，就可以使用 ? 操作符。我知道社区早就讨论过这个方案了，也被拒绝了，在这里只是吐槽下，不能接受 Go Team 拒绝的理由而已。

首先，订单成功这个描述就有点模糊。
成功提交，成功发货，还是成功配送。
建议参考 #17 ，重新定义状态

和泛型一起提出来的方案。。
像 Rust 那样 ? 不好吗
为了不承认自己设计错误，搞的大家的代码看起来那么恶心，写起来也恶心。
真是无语了

RESTful API 就是这样的，很多逻辑在前端。后端只负责业务建模，不负责前端 UI 逻辑，因为业务逻辑不会经常改变，但是 UI 逻辑经常改变。
所以现在有 BFF 的架构，一般使用 GraphQL 做 BFF 中间层。

和 spring boot 无关，和程序员有关

https://github.com/avwo/whistle 搭配 Chrome whistle 插件

和外包没什么必然联系，大厂一样有垃圾项目，小厂也一样

有阶级流动就会自然卷
不卷是因为卷也提升不了阶级
当然，卷的程度可能各地不一样，但是想上升阶级，必然要比其他人更努力
只是现在国内的卷更加明显罢了，因为人多，资源有限

这么多学的吗。
不怎么主动学， 文档什么的都看得懂，能听懂美剧的水平差不多了。

38 G 套餐，每个月送 20 G 通用，30G 定向。。