angular 从来都没这种鸟问题

我不知道首影响的行数是否与 change buffer 有关（之前不知道 changebuffer 这个概念）。

但是抛开 change buffer 不谈，可以使用 ROW_COUNT()获取上一条语句（ update or delete ）影响的行数。
https://www.cnblogs.com/langtianya/p/4776531.html

至于具体的代码...你可以让你的连接执行 2 次查询，第一次执行 update 或者 delete，第二次获取 ROW_COUNT()。如果想要一次性拿到，可以看看特定 ORM 的文档。

例如.net 的 dapper，就可以执行多个 sql，拿到多个结果。https://github.com/DapperLib/Dapper#multiple-results

火狐不会被优先适配，一些前端比较重的网站会出点小问题，例如在线文档类、视频类。
edge 全平台都有，并且内核和 chrome 一样，兼容性更好。

所以为了防止垄断，我们消费者应该 Firefox （主）+edge （辅）。现在难受点，以后好受点。

我的小新 15 寸洒过水、碘伏，现在屁事没有。

你用这么 hack 的东西，还不如把正式环境暴露给你的开发机呢。

@360511404 其实小团队可以采用 trunk-based，即大家都在 master 上面写代码，优势是保证持续集成（集成=代码合并+单元测试+xx 测试），利于防止那种几周都不合并的代码。

@bingyiyu 那你就让他在 master 写好了，估计他也不会使用除了 commit 和 push 以外的功能。你把发布分支换为另一个分支，例如 release 。

commit message 至少要能够保证：你自己过一周看到 commit message 的时候能知道这个 commit 里面干了什么。

使用 redis 只能保证不超卖——这个答案是网上随便查得到的。

完美答案是：
假设有 N 个库存，那么就得分配 N 个 token （例如 GUID ），token 放在 redis 上面以供获取。token 作为 mongo 的_id 就可以将压力平均分散到各个 shard 。shard 越多，压力越小。如果有 100 个 shard，那么压力就变为 1/100 。再用 mongo 的_id 做幂等，保证一个 token 只用一次，保证不超卖。最后通过订阅 binlog or 业务代码 将用过的 token 同步到 redis 进行标记。并且根据数据库的压力的不同可以在 redis 中对同一个 token 使用分布式锁来缓解压力，类似于避免惊群 /击穿的方案。
本方案既能保证先来后到公平性，又能保证不超卖 /少卖，还可以支持临时加库存的情况下依然能保证上述特性。

这个方案我之前面试的时候用过了，面试官挑不出刺。当然一次别说完了，不然面试官可能理解不了，挑“token+幂等”这个重点就行了。

JPA for write/transaction
SQL for query

=================

“来自”微软官方的答案。


——引号是因为微软在.net 世界给出了一个类似的解决方案。
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/cqrs-microservice-reads

查询（ read ）用的是 micro orm Dapper，命令（ write ）用的是宇宙最强 orm Entity Framework 。

虽然 ef 的表达能力几乎覆盖 sql，但是微软却告诉你：没必要全程用 ef 哦！

关键词：cqrs

断网任意浏览器扫码

在自己的工程中，叫依赖注入。注意子类要能够里氏替换。

你想一想一个是社区开源推动的产品，一个是商业公司的产品，就知道那个好用了。

简单四则运算：powershell
更多函数例如 log：powershell - python，或者 F12
更加复杂的计算：powershell - jupyter notebook
另外 excel 功能也挺强大的

谷歌能这么做是因为 Angular 强大的工程化能力允许它这么做，不是因为用了什么黑科技。
不存在什么黑科技。离线的用户体验都是用业务逻辑代码写出来的。不存在哪一种技术可以减轻业务逻辑的负担。

至于具体的业务逻辑，应该是和 git 一样的流程：本地 commit，然后再异步 push 到云端。如果发生冲突，则覆盖，或者强制用户保存到一个新的文档。我没用过 Google Docs，但是 Google Colab 就是这样设计的。

“那么像那些每次操作都依赖网络请求的系统, 如大部分业务系统、表格表单类的管理系统, 能否做到类似 Google Docs 的离线体验呢?”

回答：可以这么做，但是不推荐。如果你按照一般方法进行开发，那么 UI 就是给 api 套一层壳。如果按照能够离线使用的标准进行设计，那么还涉及到 push 的逻辑、并发修改问题、解决冲突的逻辑。既然网络不成问题，那么合并给自己额外的开发任务呢？

运动防止衰老

我的 Firefox 最近突然会假死，不知道是不是 ss 的锅。

被超是过程，晚到终点是结果。
超车是过程，早到天堂是结果。