Hypercube
Hypercube
Seems okay to me. 为了保证稳定性，的确应当锁定 Docker base image 版本
我觉得指望大家申请新镜像时写清楚信息不是非常可行，一般用户可能并不清楚各种源的最合理同步方式，即使写了“源站是某某某”，或许只是个 HTTP 或 FTP 地址，其实应该用 rsync。有的源可能还需要我们去发邮件联系，或者加入某个邮件列表/关注某个状态监视界面。并不容易从一个镜像申请看出添加这个镜像所需的额外工作量。 On Mar 1, 2019 19:48, "Bojie Li" wrote: > 我觉得没有必要硬性规定支持人数达到一定门槛才能进入正式讨论。如果一个镜像的同步方法简单，issue > 提出者已经给出上游地址，所需存储资源较少，没有版权问题，哪怕没有人附议，也可以把该镜像添加进去。毕竟对我们维护者来说，增加一个镜像并没有很多开销。 > > 此外，目前 mirror request 里面大量的 open issue 中镜像同步方法不明确，或者使用方法不明确。应当在 README 里鼓励 >...
如果要分离，当初为什么还要合并？到底是要规避什么风险，能不能说清楚？ 合并是许多前辈和指导老师为了更好地发展科大技术圈，经过讨论做出的重要决定，现在怎么能倒行逆施，一转眼就说又要分开？
> king of the hill 我觉得可以这样设计： > 比赛平台上每个人可以得到一个 token > 每道题有一个题目 token > 题目后台向比赛平台 POST 分数、用户 token、题目 token，平台就会记录分数
是的，以前认为每个题目包含标题、描述文字、一个“打开题目”链接，这种模型是错误的。题目可以有很多种链接，我能想到两种正确的建模方式： 1. 题目有“网页”、“nc 连接参数”、源代码文件等多个字段，哪些非空就在界面上显示哪些，配上合理的图标 2. 把链接的概念从模型中去掉，题目作者自己在“描述文字”底部写上即可，但平台提供一些预置的 CSS class，以便显示效果统一 另外，有时题目描述中需要插入一点动态内容，例如一个链接，它带着选手 token 作为参数。目前的解决方法是 https://github.com/ustclug/hackergame/blob/159812f625564e7043e8df800df7c58d7bd0b356/frontend/templates/hub.html#L99 和 https://github.com/ustclug/hackergame/blob/159812f625564e7043e8df800df7c58d7bd0b356/frontend/templates/hub.html#L102 （强行替换）不知道有没有更好的做法，但我觉得选上面说的第二种方法，配合这个就可以
注意排行榜缓存的设计
> 如果真的这么做的话，我们很可能会让校内排行榜使用校内解出人数对应的分数。