Putong OJ v2.0 开发过程中的踩坑记录

在学校指导老师的要求下,同时 Kerminate 想把写 OJ 作为毕业设计的情况下,我和 Kerminate 决定开发 2.0 版本。具体的特性已经在项目地址 PutongOJ 说明。这里主要说一下这次开发中的坑。

项目文件结构

在后端结构上,直接采用了之前的项目文件结构,结果可以看到,几乎所有文件夹都放在项目一级目录下,包括 controller, model 文件夹等。现在看来,应该都把它们放在一个 src 文件夹下的。因为如果采用这种方式,那么使用 babel, tsc, eslint 等工具时,可以更方便的指定需要操作的文件夹。不然现在,如果我要使用这些工具,我需要指定一些需要被工具 ignore 的文件夹,比如 public (里面可能包含一些编译好的前端 js 文件)。

i18n

原先计划是全用英文的,因为觉得大多数单词都很常见,比如: Problem, Status, Wrong Answer 等。而且,正式比赛里,题面都是英文的,因此正常情况下,使用者对英文是不会排斥的。

但是这里我想错了。有很多使用者其实会排斥英文界面。究其原因,一是因为指导老师除了在 acm 教学上会使用 OJ,在平时其它授课,比如 C 语言等,仍然会使用这个 OJ:在这个情况下,这些使用者,也就是学生,大多不会参加 ACM,也觉得做英文界面是多次一举。另外就是,很多使用者是大一学生,大部分英文水平还没经过四六级的磨练,而且有些高考英语也不怎么好,因此在英语水平上可能并不是特别理想。

就像有些人,一看到书上密密麻麻的数学公式时就会选择直接跳过不读一样,一些学生看到英语也会直接跳过不读。

在这个要求下,我觉得加上 i18n 支持是必要的。而且现在几乎所有现代网站都有 i18n 支持,实现这个功能对增加用户体验也是挺有好处的。如果未来有机会,再实现这个功能吧。

docker 中允许 ptrace 操作

OJ 判题端使用到 ptrace 对子进程进行跟踪控制。但是在默认情况下,在 docker 容器内,这项特性是不被支持的。

起初我注意到了判题端总是 ptrace 失败的问题,但我一直猜测原因出在判题端本身的实现上。直至我偶然情况下,没有在 docker 容器内测试,而是在一台 linux 服务器上测试时,才发现此时判题端并不会出现 ptrace 失败的问题。之后也猜测了是否是 docker 容器的 linux 版本的问题,不过幸运的是,直接在 google 上以 docker ptrace 为关键字搜索就能知道问题原因。

解决方案就是开启 docker 对 ptrace 的支持。如果是 docker-compose file 的话,只需加上

1
2
cap_add:
- SYS_PTRACE

前端 UI 库的选择

在最开始挑选 UI 库的时候,我首先把 Material 风格的给排除了。原因是个人认为 Material 风格不适合 OJ。

而主要负责前端编写的 Kerminate 首先使用的是 ElementUI,但 Kerminate 反应这个并不好用,因此又选择了 iView (虽然采用了 iView 了后,也抱怨过 iView 有些组件也不好用)。

记得当时可选范围限定在了 awesome-vue 列表上出现的 UI 库。与当时相比,现在比以前增加了 5 个左右,而且现在增加了 vue-antd-ui

目前 UI 库使用的是 iView,至于如果有 v3.0 的话,要不要换 UI 库,就看那时候的 OJ 维护者了。

未来计划

i18n

这个上面提过,个人认为有必要支持。

TypeScript 与 egg.js

其实 v2.0 就可以用上 TypeScript。只是当时觉得好像这个项目这么小,用不用也无所谓。但现在想想,为后来的维护者们考虑,使用 TypeScript 可能对他们理解和维护项目能有所帮助。

至于 egg.js 么,虽然我是随意了,不过有很多人向我推荐啦。如果我觉得确实好的话,就考虑未来用上吧。