identifier++ 是先增，它的值是自增后的 identifier.
语义上等于 identifier = identifier + 1

C 解释器一直在用 picoc （
Cling 好像听说过

之前看某同学的《相对论》（反正是和相对论相关的书）（看不懂2333）
讲狭义相对论，说有一个大漏洞，连小学生都不会认同，化简出来是这样

当 y != 0 时，
  x + y = x

逻辑符号语言上可以这麽说（我居然查了几十分钟）（逻辑还是 Agda 更有意义，虽然我没空学）：
（胡话，如果不学逻辑 Semic 我无法设计啊....

wiki

¬(y = 0)→x + y = x

有人反对，但理由不是很通顺，所以我打算使用 Hexo + MDUI 写 GitApk

（开始是打算用 C 的，模板引擎也打算手写，考虑到效率）

这些是目前 GeekApk 最有价值的文档

包含了两种准备好的文档

GeekApk 最重要的东西 - 设计文档，虽然没有包括 API 文档

唯一一个做出来的服务...

项目模板

GitApk 会在 Hexo 和 Gitea 后端的支持下开始

考虑考虑...

入门 Hexo 插件开发还要时间，写模板我又不是很熟悉前端...

但之前几次不是模板的前端都做得

先试试 Swagger 吧

临时就使用静态网站生成器和部分裸 Gitea 的页面（以后自己做前端）完成 GeekApk 了

扩展暂时只支持自定义 install uri handler，不支持内嵌 code

对于用户，Gitea 的用户就是 GeekApk 的用户，虽然可能损失一些数据，GeekApk 无需进行任何其他的处理

用户的「Meta repository」 会包含用户的 bio： README.md

用户的 nickname：nickname 文件
自定义头像：avatar 文件

还有用户的 Star 文件夹：/star/
和时间线 issue：#1

对于分类，Gitea 「GeekApk 元数据源」 里的文件夹会区分分类，静态网站生成时会生成按照星标和更新时间排行的分类索引

同时，也会生成分类对应用集合的索引

对于应用，就是一个具有元数据表的 Hexo 文章，它的内容是应用的 README
aid、package、description、author、name、icon、screenshots、created、updated、issue、latest

其中，aid、package、name 是必须有的，不然拒绝生成

静态生成器具会生成 csv 索引。包含应用最新版本索引、包名索引、author 索引、description 索引

静态生成器也会生成应用列表的 JSON 文件、以及每个应用的 JSON 文件

对于更新，是 README 中的一个子章节，它的标题是 Updates，插件会将它处理成 JSON 数组的格式，和分 reversion 的 JSON 对象格式

## Updates

### 0.1.0

+ reversion is 1
+ minium required sdk is 17
+ install url https://foo.baz/foo.apk
+ created at 2018-08-12T03:37:13.537Z

#### Changes

Changes text here

对于评论，暂时使用 Gitea issue 讨论版功能替代
我们可以看到每个应用都可以指定一个 issue id，作为自己的留言板

对于时间线，Gitea 没有时间线，但是用户可以 「watch」 一个 repo（不过打算使用 watch issue 实现，性能更好），这样，用户维护自己的「GeekApk 用户元数据」源（的 「时间线」 issue），即可实现时间线功能

「可以自动记录的操作」
• 用戶 跟随 了某个用戶(1)
• 用戶 创建 了某个评论(2)
• 用戶 星标 了某个应用(6)

「手动维护的 Gitea PR 操作」
• 用戶 提交 了某个应用(3)
• 用戶 更新 了某个应用(4)
• 用戶 删除 了某个应用(5)

对于通知，Gitea 原生自带了通知功能，GitApk 不会包装这个功能（通知的情况只有一个，就是 @，因为其他的 Gitea 都有功能）

对于星标，用户自己维护自己的「star 元数据」，并在应用对应 issue 的一楼点赞 ❤️ 即可

GitApk 是在 Gitea 等社交源码托管站点上建立的

已经基本实现了之前 GeekApk 的设计特性

但是有一个缺点：更新检查比较慢
（然后发现好像有最新版本的 csv
这样就不慢了
（有点类似 FDroid