Scratch3.0技术分析之后端API(第0篇)

近期我们计划对Scratch3.0做一系列的技术分析,这是这个系列的开篇。

我们致力于实现以下目标:

  • 理解Scratch3.0的架构设计
  • 理解Scratch拥有强大兼容性的原因
  • 梳理Scratch3.0产品背后使用的一些设计原则
    • 表现与实现的分离
    • 事件驱动
    • 面相对象
    • everything is message
  • 按照Scratch一贯的设计原则,独立实现Scratch并未开源的部分。确保之后能随着Scratch一同升级,架构上保证向后兼容。
  • 顺着Scratch的思路,对Scratch作出改进。

总而言之,我们希望通过这些分析,获得定制scratch的能力,但同时又能与上游的官方版本保持兼容。我们重视官方对Scratch的改进。与其说我们重视他们技术能力,不如说我们重视他们对教育和社区的深刻理解,这些是极为稀缺的,它不是技术问题,也不是资金问题。我们希望能随时将官方的改进merge回我们调整后的项目中。我们不希望做出硬分叉。

Scratch3.0 正式发布

Scratch3.0于2019.1.2如期而至。

Scratch3.0的GUI社区的前端都已开源:LLK

你可以在线体验一番.

目前Scratch3.0团队没有透露社区后端和GUI的存储部分是否有开源计划(我们之后将这两块统称为后端),我此前和Scratch3.0后端团队成员做过沟通,他提到Scratch3.0后端目前同时采用了新构建的REST API和之前遗留的Django server。他们陆续将一些基础服务从Django中迁出,转化为API对外提供服务。从我们之后的分析中可以知道,他们新的后端基于restify。我想官方的技术选型主要出于restify对REST的友好支持,以及restify应对高负载的能力,毕竟Scratch社区有3000万用户。

考虑到Scratch2.0的后端并未开源,3.0社区后端开源的概率估计也不大。个中原因可能是防止社区分裂。毕竟每家公司跑一个scratch社区挺奇怪的,它分裂了用户群。更何况,大多数的公司采取的教育策略,正是《终生幼儿园》所反对的。

除了Scratch3.0的社区后端,Scratch3.0的其他部分,官方都有计划开源,包括desktop,终生幼儿园小组正在和MIT校方沟通推进这件事,这些信息在scratch团队日常的讨论中有提到。

为何做这个分析

Scratch3.0的社区与插件系统,将开放到什么程度?官方的计划是什么?目前scratch团队并没有给出明确说明.他们在FAQ中提到说这部分的工作还在进展中。

我们(codelab.club)今年(2019)上半年有计划与scratch team碰个面,如果官方接受,我们希望将codelab-adapter集成到官方项目中。帮助Scratch3.0连接到更广阔的世界(education as life),同时建立Scratch3.0与Python(或者任何其他语言)的无缝连接。如果官方没太大合作意愿,也不愿开放接入机制,我们将独立构建用户社区。我们仍鼓励用户使用scratch官方社区(如果网络顺畅),因为那里边有丰富而友好的的人群,海量的不可思议的创意项目,以及scratch团队令人称赞的运营方式。但对于那些官方不支持的创造,尤其是与生活相关的创造(education as life),我们将提供另一个社区来支持用户。我们的目标是让万物积木化,支持更广泛的创造。支持杜威提倡的

education as life

我们关注如何构建出兼容官方已有开放项目的后端,让用户保持一致的使用体验。同时也保证我们随时可以merge回官方的最新进展。我们另有一个野心是在我们的实现中加入activitypub,让scratch的社区数据,轻松支持跨站共享和分布式存储。 codelab.club是一个非营利组织,这是我们希望支持落后地区的一个举措。让我们设想一种场景,在贫困山区,网络并不通畅,如何帮助那儿的孩子接入到社区中?他们如何了解社区最近创造出的有趣的项目(projects)?而peers和projects是scratch很核心的2个概念。有了activitypub,我们在山区中可以使用树莓派跑一个scratch社区后端,孩子们可以在局域网内形成社区(一台树莓派即可,树莓派可以发射热点构建局域网)。当志愿者到来,开放出手机热点,activitypub将为他们把外部世界的数据同步进来。很多的手机卡已经几乎免流量了。这件事没有想象的那么困难,即便在经济上也没有。

activitypub可能起作用的场景当然远不止贫困山区。关于这块的可能性有空在谈。

为了支持我们上边提到的所有目标。我们需要分析目前官方的后端API(其他开源的部分我们也将分析)。我们看到scratch为兼容性这块付出了巨大的努力,他们精心设计了数据的结构,他们花了很大精力来保持对旧版本的兼容,他们甚至希望兼容到1.4版本(十年前的项目!). Scratch团队始终不抛弃已有的用户和用户创作的项目,很难看到比scratch team更尊重用户作品的组织了,这是一群令人肃然起敬的教育者。

整理已有的Scratch API相关文档

社区里目前有不少Scratch后端API相关的文档和项目。

在此做个梳理。

这些项目是Scratch2.0的API,但Scratch3.0和2.0的API基本是相同的。主要原因我们前边有提到: 出于兼容性的考虑。

我在完成这篇文章的途中,也会顺手给出scratch3.0的api文档,如果时间允许,我还将给出Python实现的Scratch client。

此外,也可能顺手实现Python版本的scratch-parser,这个工具将来会成为我们为scratch用户制作画像的基础,由于Python社区的数据分析生态最成熟,所以我计划用Python来做。评估Scratch用户的学习效果,以及用户对知识的掌握情况,我认为目前是项目驱动的平台(如scratch)存在的痛点。我们希望这个项目支持所有Scratch平台,只要大家兼容官方的数据结构即可。这就是我们如此重视兼容性的原因,因为这样有助于打造通用的工具链。

评估学习者的学习进展并不容易,我认为对程序的静态分析可能是突破口之一,所以我们需要重新实现scratch-parser。在静态分析的基础上,加上一些机器学习的算法和推荐系统,将来甚至可以做到,针对用户的学习情况和兴趣点,给他推荐可能感兴趣的人与项目。如此一来,线上平台就部分实现了我们希望在club中实现的东西:帮助用户去寻找和发现感兴趣的projects与peers。

工作计划

我们的分析工作从创作平台开始。

之后转向分析社区

我们相信这一系列的文章对于准备使用Scratch3.0作为公司基础项目的产品经理和系统架构师会有价值。

文章列表

截止到2019.01.15这个系列的分析文章基本写完了,整理如下:




Fork me on GitHub