在一段时间的停滞后，项目进行到了基本API和框架完备的阶段，是时候开始开发真正让这个OJ不同的评测系统了。

评测系统执行架构设计

去年年末，我开了一个评测机新坑Shikieiki(名字取自東方花映塚封面角色 四季映姬·夜魔仙那度)，调研了一些和评测相关的技术。长期以来，大家有一种设想，使用类似CI/CD的方式配置某种通用的评测系统，社区中也有诸多实现(如Seele)。但并未有一个有足够通用性和健壮性处理大量通用评测任务的评测系统。Shikieiki的目标便是打破这一现状。基于Rust，我们可以设计快速高效的分布式评测系统。具体而言，Shikieiki目前有以下核心构想：

• 动态加载的，节点化可配置的评测任务设置
• 分布式的评测后端
• 基于容器化技术的安全评测环境
• 可配置的评测前端选项

接下来，我将简述目前实现这些构想的技术方案。

基于deno_core，Rust支持在运行时直接执行JavaScript/TypeScript代码，有鉴于此，我们不妨基于TypeScript设计一种插件形式。具体而言，一个插件的后端部分可能需要包含如下代码

// metadata.json

{
    "id": "1234abcd-5678efgh-9012ijkl-mnopqrst",
    "version": "1.0.0",
    "description": "This is a sample node config.",
    "inputs": [
        {
            "name": "files",
            "type": "fileList"
        },
        {
            "name": "integer",
            "type": "integer"
        }
    ],
    "outputs": [
        {
            "name": "files",
            "type": "fileList"
        },
        {
            "name": "integer",
            "type": "integer"
        }
    ],
    "config": [
        {
            "name": "config1",
            "type": "string"
        },
        {
            "name": "config2",
            "type": "integer"
        }
    ]
}  

// index.ts

import { type FileList, PluginError } from '@guoj/aya';

export interface Inputs {
    file: FileList,
    integer: number
}

export interface Outputs {
    file: FileList,
    integer: number
}

export const process = (inputs: Inputs): Outputs => {
    if (!inputs.file || inputs.file.length === 0) {
        throw new PluginError('No file provided');
    }
    if (typeof inputs.integer !== 'number' || isNaN(inputs.integer)) {
        throw new PluginError('Invalid integer provided');
    }
    // Process the file and integer here
    const processedFile = inputs.file; // Placeholder for actual processing logic
    const processedInteger = inputs.integer + 1; // Example processing: incrementing the integer
    return { file: processedFile, integer: processedInteger };
}

(基于rust shared library的插件规范开发中)

不仅如此，一个插件还可以携带一个可选的WebComponent(也可使用带有自动生成功能的模板)用于前端可视化。如：在工作流的起点节点使用一个带有传统OI提交功能的节点，在工作流的终点节点使用一个带有传统OI结果输出的节点等。通过多个节点构成的工作流，还带有一些选项可用于配置工作流执行所在的镜像环境等。通过这一系列基础设施，我们得以实现一个既多功能又足够通用的评测框架。

评测系统分布架构设计

在单节点的通用评测系统支撑下，我们希望引入更多的分布式机制帮助我们构建一个强大的多节点评测系统支撑一个现代化的计算机社区。具体而言，我们希望在全局评测机群，允许用户引入自己的评测机群，并允许配置评测机群拉取指定习题/习题集的评测队列执行任务，并实现一定的调度机制使得自托管的评测机可以使用较少的资源运行用户希望他们的评测机执行的任务(如为自己的客制化习题集/比赛提供高质量服务)，也允许用户为全局评测机群贡献自己的力量。在这样的愿景下，目前我们认为有这样的问题有待解决

• 如何实现高效的评测状态管理系统为每个节点分配任务，并避免评测队列中出现错误
• 如何避免不合法的评测机连接(对私有评测机而言似乎不是问题)
• 如何认证合法的评测机加入全站评测队列(目前而言，基于真实信任并丢弃产生非法结果的评测机)
• 如何减小评测机性能差异的影响(为特定任务实现某种基准评测机评分，并允许用户选择高效评测机为自己服务或是自己搭建评测机)

因为某个名噪一时的事件，我注意到了一些网络笔记软件。一个类似Telegraph、GitHub Gists的想法在我的脑海里逐渐浮现出来，同时为了满足自己的造轮子欲望和推广一个Markdown WYSIWYG(What you see is what you get, 所见即所得)编辑器Milkdown，于是开了这个坑。这里堆放对这个项目的思考与预期。

Concept

Akyuu是一个基于Markdown的轻量化Web笔记软件，支持丰富的扩展语法。Akyuu的理念是“简单，但并不简单”。相比Obsidian、Notion等兴起的笔记软件，Akyuu没有单文本编辑以外的功能，也没有独立的客户端。Akyuu仅提供Web服务与PWA客户端。相比Telegraph，Akyuu不与其他认证提供服务绑定，同样仅用一个URL标识一份文本。相比于GitHub Gists，Akyuu仅用Markdown以及一系列扩展语法功能作为你的文本格式。Akyuu的目标是成为任何用户随手可用的Markdown编辑器。Akyuu的目标是使用Markdown作为框架实现简便快速的富文本编辑体验。Akyuu的目标是基于扩展Markdown语法支持用户自由表达一篇文章需要表达的任何内容。

Auth

Akyuu的认证方式不同于上述所有文本托管服务。Akyuu没有传统的用户概念，仅对每篇文章保留一个访问属性(public、protected、private)。任何用户可以访问修改public文章，任何用户可以访问protected文章，文章拥有者可以访问修改private文章。Akyuu除了每篇文章可选设定的作者项（基于Gravatar等服务提供头像），仅对非public文章保留一个认证字符串，对private文章保留一个访问密码。此字符串可为随机字符串，可为手动设定字符串，也可为不可见的基于SSH/GPG密钥签名后的字符串。Akyuu支持用户设定他们的SSH/GPG密钥(完全随浏览器保存于本地)并可选加密密钥，同时也支持使用GPG签名文章。我们相信这种简化的认证模型适用于普通的用户，也适用于进阶用户。

More Than Markdown...?

Akyuu基于remark、prosemirror、milkdown等技术，目标是通过支持LaTeX、Mermaid、Typst等第三方语法，通过基于Markdown扩展对齐、上下标、注音、提示语法，通过支持插入第三方视频、PDF等方式，扩展Markdown的表达能力，同时保留Markdown的低复杂度富文本语法。在简约的UI/UX下拥有一颗富于表达的内心。

Intro

经过多年的拖延、重构、再拖延、再重构，GuOJ这个项目在长期停滞之后重新开始活跃。使用最新的技术栈，我们希望能尽快将这个被我们寄予厚望改变算法竞赛乃至计算机学习生态的平台变为现实，让这只长期咕咕咕的鸽子插上自己的翅膀展翅飞翔。

Briefing

GuOJ，正如其名，是一个在线评测系统（Online Judge）。在此之前，从最早的Uva Online Judge，到国内出现的 Universal Online Judge、LibreOJ，再到目前被普遍认可和使用的CodeForces，在非竞赛领域被广泛使用的LeetCode，在线评测系统经过了多年的迭代已经成为了任何对计算机科学抱有兴趣的人或是相关从业者不可忽视的学习工具，同时也成为了部分计算机爱好者社区的中心。然而，多年来在线评测系统与其相关社区的潜力却远远未被完全发掘。这个项目的目的便是研发并实际建设下一代在线计算机科学社区。而针对这一目的，我们希望提升这些方面的体验：

• UI/UX设计
• 评测系统可配置性
• 评测服务可伸缩性
• 社区交互性
• 开源模式可持续性

本次的Dev log，我们将讨论项目的开源模式与评测系统问题。

Open Source + Community

怀揣着成为下一代评测系统+社区的目标，为了使更多人能够加入进这个项目并促进这个项目的健康发展，我们决定以AGPL-v3协议发布这个项目的所有源代码，欢迎任何人加入这个项目的开发。这是一个并不容易的决定。开源项目意味着商业公司可以容易地挪用、借鉴甚至抄袭这个项目的核心特性，并且也面临着社区管理去中心化等等诸多问题。但我们认为通过我们项目的核心理念，开源终将成为我们的优势。项目本身将可以成为对于这一方面开发有兴趣的人的学习资源，开放的理念可以为我们吸引怀揣有同样理想的人们，本身去中心化与可伸缩性的服务也能为我们创造服务的不可替代性和将来竞争者需要考虑的成本因素。我们希望通过为任何人托管开放或私有的题库、托管他们的评测队列服务并协助他们管理他们自己的评测机阵列、为社区托管完全开放自由的题库与比赛来创造我们自己的独特性与不可替代性，并通过类似ppy/osu等社区项目的运营模式，通过服务本身以外周边的订阅、售卖为项目本身创造支持其进行下去的收入。我们相信这是一条能够避免商业化来保持学习计算机科学这件事本身及其乐趣的纯净的路，于是我们选择了这条路，正如我们的前辈们一样。但不同的是，我们立志以高质量的代码、精心设计的用户体验、前所未有的社区功能提供全新的体验。

Next-gen Judge System

在已有的草案中，我们决心为这个项目的评测系统部分打造一个全新的可配置的可伸缩的评测系统。我们计划基于Rust开发一个通用的评测终端，旨在能够作为任何下一代评测系统的基底。我们将制定一种类似CI/CD系统的评测配置文件标准，并提供可复用的配置模板确保配置友好性与向下兼容性（例如支持传统的逐行比较或是较新的testlib评测方式）。我们希望借此满足目前计算机科学领域大部分可以通过评测方式解决的代码实践检验能力。同时，我们将基于此开发一个本地评测管理工具，提供沙盒管理服务与评测任务处理机制，能够自动管理评测数据与评测任务，并生成评测沙盒环境完成评测任务。我们希望这个终端软件同样是渐进式的，它可以充当小型本地评测系统（类似Cena、Lemon的软件）的任务处理与安全管理工具，也可以成为我们评测客户端的任务执行工具。在此之后，我们希望实现一个微服务（类似fold@home的思想）能够从我们站点的评测队列拉取评测任务与评测任务相关的题目数据文件，并且让任何人都能部署自己的评测微服务终端，可加入我们站点的公共评测机池为全站评测提供服务或是加入自己的私有评测机池为自己在本站托管的私有题库提供评测服务。

What's Next

GuOJ还处于早期开发阶段，目前我们已经确定了第一个迭代的技术栈并将其发布在GitHub。目前我们使用PostgreSQL作为项目的数据库，使用Bun+ElysiaJS开发后端服务来确保功能的快速迭代，使用Nuxt3开发前端服务并确保SEO服务。同时，我们正在尝试新的技术来提高我们的用户体验与内容展现能力。我们正在基于unified与remark开发一套全新的开箱即用扩展markdown语法标准与渲染解决方案fremark，并正在探索在其中同时实现typst和LaTeX作为公式渲染器的实现方式。我们同时也参与了一个WYSIWYG（What you see is what you get, 所见即所得）markdown编辑器milkdown的开发工作，并计划未来将二者应用在我们的项目中。