@xarthur 如果用户使用的是 b 站追番，那么导入直接可以使用自动化脚本（ readme ）。如果使用的是其他追番方式，现在暂时没考虑

某些逢中必反的人脸疼不？谁下架的？

@no1xsyzy 认真考虑过。但是如果 sha256 遭遇危机，先担心的应该不是我的应用，而是 BTC 、BCH 。同理，如果硬盘坏掉的概率小于陨石毁灭地球的概率，那么就应当先担心陨石撞击地球，而不是硬盘。

@no1xsyzy 简单来说，就是把一段时间内所有在平台提交的记录建立一棵树，将树根的 sha256 记录在链上。由于 sha256 很难碰撞，且尚未发现任何一例碰撞，所以树根的存在可以推导出叶子的存在。另外，关于文章中自带作者信息，可以自己加上，也可以放在仓库里的单独文件（ copyright-info ）中。详情请看本项目的 github 仓库 readme 。


@ysmox arχiv 有 arxiv 的定位。在 arxiv 上面发表文章也需要经过时间审核，并且可能被拒。发布的论文也是完全公开的。另外，如果每天的研究成果和数据都在 arxiv 上发布，那么频率会太高。
本项目借助区块链的性质，能保证绝对的准确性。本项目能够在不公开文件信息的情况下，保护每一个版本的论文、代码、实验数据等一切文件。相比于 arxiv 来说门槛更低，甚至不需要 edu 邮箱。

换一种思路。一个健壮的程序应当能够完美应对以下情况：

在断电 /断网后，数据库的完整性依然能够保证。

这就要求你在处理任务的时候充分发挥事务和幂等性的作用。

{get; set;}

@krixaar 这个工具对于明面上的侵权（例如文章、博客、视频创作）当然防不了。但是对于论文、科研数据等涉及名誉的，还是有保护作用的。

这学期我们选修课讲师在课上聊天，说他之前发表的论文被审稿人之一拒了，然后那名审稿人的学生紧接着发布了相似的论文，连数据都是相同的。

所以我想，有了这种零门槛的工具，研究人员就可以将每一天产生的数据都保护起来。

@njutree 纯 sha256 在数学上就可以拥有绝对的证明效力的，可以看仓库里的“延伸阅读”。另外打包的时间是可以设置的，当然太频繁打包的话，钱包遭不住（打包一次平均耗费 400satoshi 左右的 BCH，合 0.015RMB ），所以就设置为 12h 打包一次。

书籍已经存在了多久，那么它就将继续存在多久。

Lindy effect: the future life expectancy of some non-perishable things, like a technology or an idea, is proportional to their current age.

Lindy effect proposes the longer a period something has survived to exist or be used in the present, it is also likely to have a longer remaining life expectancy


https://en.wikipedia.org/wiki/Lindy_effect

使用 mysql 的 json 类型。

关系型数据库

@8e47e42 我是重度耳塞使用者，每天都用，从不间断，从未感染。推荐安耳悠的耳塞，或者零听（零听舒服一点）

“音乐高雅耐听，歌词写的用心”

高雅还是通俗，主要应该看歌词吧，和作曲编曲关系不大吧。还有，你用“高雅”的意图何在？外文歌给你带来的优越感已经在不知不觉中飙到键盘上了。

歌词写的用心：恕我直言，是外文歌的陌生感带给听众的高级感。


不可否认周杰伦近年来有下滑（许嵩说，艺术创作的最大敌人是安稳的生活）。但是周杰伦好歹也是开创一个时代的音乐人，很多音乐人也曾将周杰伦视为偶像，据我所知的就有许嵩、谢帝。

幼稚，因噎废食

技术文档又不是英语阅读，不会刻意为难读者的。比如你去看 Postgres 官方文档，生词就只有一些数据库方面的常见名词，这些名词你读中文文档也会遇到的。

还有一个就是兴趣。如果对某领域的兴趣特别浓厚，那么开始的时候阅读英文信息可能会难一点，但是兴趣可以让你坚持下去。看多了就熟练了，恐惧感也完全消失。

buff：对某个技术 /框架的兴趣
debuff：对英文的恐惧、被 DDL 压迫的欲速（不达)

---

@KyonLi 框架是帮助开发者干净地安排业务逻辑的。深度学习框架 vs Web 框架：Web 的业务逻辑很容易懂，与现实世界的业务逻辑相关；而深度学习框架的业务逻辑是和深度学习相关的。所以想要使用深度学习框架，必须得学习深度学习方面的课程。

@xiaofan2 不一定是 ID，时间戳字段也行。另外时间戳可能无法保证最新数据的插入顺序，但是一段时间之前（例如 10 分钟）的数据的顺序是稳定的。

对于插入顺序的保证：我去调研了一下，单机的可以保证（例如 MySQL AutoIncrease ），但是分布式的不能保证（例如 mongo ）。此时一个解决方案是上文所说的（同步一段时间之前的数据），另一个解决方案是使用能够保证插入顺序的消息队列服务，例如 kafka 。

解决数据丢失：
方案一：借助数字 ID 的连续性。这个很好理解吧。如果 id 不是连续的，或者不是数字，请看方案 2.
方案二：只需要合理设计接口即可。具体见下面的例子。
方案三：使用 outbox pattern （交易记录增加一个字段“是否已同步”），需要借助最少一次送达的消息队列。https://microservices.io/patterns/data/transactional-outbox.html

方案 1 和 2 非常类似，属于数据接收方主动。方案 3 属于数据持有方主动。

---
举一个方案 2 的具体例子：

（先假设 id 的大小关系和时间的大小关系一致，或者说后插入的数据 id 大）

数据持有方这样设计请求接口：
GET /records?start=1001&count=500
response: { data: [...], hasNext: True }

这样设计的好处：
1. 批量操作（参数 count ），效率损失少。
2. 不会错过数据。接收方每次查询时，只需要将 start 设为自己数据库里面最后一条 id 即可。

注意：对于数据发送方是分布式数据库例如 mongodb，为了防止“后插入的数据 id 大”这一假设被打破，应当合理设置 read concern 。

---

具体是方案 2 还是方案 3，就见仁见智了。我个人认为方案 2 灵活性强，学习成本小，利于团队间合作。

性能方面的建议：
削峰。同步数据的工作分散到每一个小时，而不是每天结束时做。

如果你的容器是生产环境的话，那么日志是比较好的排错方案。

如果你的容器是开发环境的话，那么应当尽量选择熟悉的、成熟的的环境作为开发环境。但是直接在容器里面 debug 的技术还是存在的，VisualStudio 就已经支持将容器作为开发环境的 debug 。

你这个差距也太大了，一个差距是准备 vs 没准备，另一个差距是学校教学的差距。
好的 985，学生做完实验后，进程、线程都刻在 DNA 里面了，十年都不可能忘。