Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion docs/cs-basics/network/other-network-questions.md
Original file line number Diff line number Diff line change
Expand Up @@ -195,7 +195,7 @@ ECDHE 不直接传输共享秘密。客户端和服务端各自生成临时密

所以一句话总结:**RSA 是客户端把秘密加密送过去;ECDHE 是双方用临时密钥协商出秘密。ECDHE 支持前向安全,也因此成为现代 HTTPS 的主流方向。**

详细介绍:[HTTPS 握手里的 RSA 和 ECDHE,到底差在哪?(应用层)](./https-rsa-vs-ecdhe)
详细介绍:[HTTPS 握手里的 RSA 和 ECDHE,到底差在哪?(应用层)](./https-rsa-vs-ecdhe.md)

### ⭐️ 有了 HTTP,为什么还要 RPC?

Expand Down
2 changes: 1 addition & 1 deletion docs/distributed-system/distributed-id.md
Original file line number Diff line number Diff line change
Expand Up @@ -540,6 +540,6 @@ Java 语言使用示例:<https://github.com/yitter/idgenerator/tree/master/Jav
| **Snowflake** | 高 | 趋势递增 | 中 | 大中型分布式系统,需要处理 Worker ID、时钟回拨和容量规划 |
| **UUID v7** | 高 | 趋势递增 | 极低 | 云原生、无中心化集群、追求开箱即用;主键场景仍建议唯一索引兜底 |

不过,本文主要介绍的是分布式 ID 的理论知识。在实际的面试中,面试官可能会结合具体的业务场景来考察你对分布式 ID 的设计,你可以参考这篇文章:[分布式 ID 设计指南](./distributed-id-design)(对于实际工作中分布式 ID 的设计也非常有帮助)。
不过,本文主要介绍的是分布式 ID 的理论知识。在实际的面试中,面试官可能会结合具体的业务场景来考察你对分布式 ID 的设计,你可以参考这篇文章:[分布式 ID 设计指南](./distributed-id-design.md)(对于实际工作中分布式 ID 的设计也非常有帮助)。

<!-- @include: @article-footer.snippet.md -->
Original file line number Diff line number Diff line change
Expand Up @@ -50,7 +50,7 @@ head:
在和出版社编辑沟通前,我也和图书公司的工作人员交流过,不少工作人员对我也是比较尊重,交流虽然不算深入,但也算客气。不过最终对比出版社给出的稿酬等条件,我还是没有通过图书公司出书,这也是比较可惜的事情。下面我给出些具体的经历。

- 我经常在博客园等地收到一些图书公司工作人员的留言,问要不要出书,一般我不问,他们不会说自己是出版社编辑还是图书公司的工作人员。有个别图书公司的工作人员,会向作者,尤其是新手作者,说些“出版社编辑一般不会直接和作者联系”,以及“出书一般是通过图书公司”等的话。其实这些话不能算错,比如你不联系出版社编辑,那么对方自然不会直接联系你,但相反如果作者直接和出版社编辑联系,第一没难度,第二可能更直接。
- 我和出版社编辑交流大纲时,即使大纲有不足,他们也能直接给出具体的修改意见,比如某个章节该写什么,某个小节的大纲该怎么写。而我和个别图书公司的工作人员交流过大纲时,得到的反馈大多是“要重写”,怎么个重写法?这些工作人员可能只能给出抽象的意见,什么都要我自己琢磨。在我之前的博文[程序员怎样出版一本技术书](./how-do-programmers-publish-a-technical-book)里,我就给出过具体的经历。
- 我和出版社编辑交流大纲时,即使大纲有不足,他们也能直接给出具体的修改意见,比如某个章节该写什么,某个小节的大纲该怎么写。而我和个别图书公司的工作人员交流过大纲时,得到的反馈大多是“要重写”,怎么个重写法?这些工作人员可能只能给出抽象的意见,什么都要我自己琢磨。在我之前的博文[程序员怎样出版一本技术书](./how-do-programmers-publish-a-technical-book.md)里,我就给出过具体的经历。
- 由于交流不深,所以我没有和图书公司签订过出书协议,但我知道,只有出版社能出书。由于没有经历过,所以我也不知道图书公司在合同里是否有避规风险等条款,但我见过一位图书公司人员人员给出的一些退稿案例,并隐约流露出对作者的责备之意。细思感觉不妥,对接的工作人员第一不能在出问题的第一时间及时发现并向作者反馈,第二在出问题之后不能对应协调最终导致退稿,第三在退稿之后,作者在付出劳动的情况下图书公司不仅不用承担任何风险,并还能指摘作者。对此,退稿固然有作者的因素,但同是作者的我未免有兔死狐悲之谈。而我在出版社出书时,编辑有时候甚至会主动关心,主动给素材,哪怕有问题也会第一时间修改,所以甚至大范围修改稿件的情况都基本没有出现。
- 再说下图书公司给作者的稿酬。我见过按页给钱,比如一页 30 到 50 块,并卖断版权,即书重印后作者也无法再得到稿酬,如果是按版税给钱,我也见过给 6%,至于图书公司能否给到 8 个点甚至更高,我没见到过,所以不知道,也不敢擅拟。

Expand Down