@Caven 是年会主持人, 有天找我聊天:
咱们能否做一个程序来支撑年会游戏？游戏规则是这样的: 每人从 1-100 之间选一个数字提交（有必要是整数）。对所有人提交的数字做一个算术平均，谁的数字和这个平均值的一半最接近，谁就取胜。如有相同答案，则先提交者取胜。
这是个经典的博弈游戏，对此感兴趣的同学能够参阅: 猜数字游戏的最佳战略是什么？。年会游戏的成果与前文的定论很符合，定论似乎具有社会计算学意义 ：）
在此，咱们不继续评论游戏本身。接下来将共享咱们完结的游戏程序。
心路历程
有过 Web 编程经历的人，首先会想到这样的计划: 运用前后端架构（CS 架构）。前端网页用于用户交互, 从游戏规则说明到数据提交，这类的作业都应该放在前端。后端则用于收集用户提交的数据，并履行事务逻辑，在此的事务逻辑是
对所有人提交的数字做一个算术平均，谁的数字和这个平均值的一半最接近，谁就取胜。如有人提交了相同的答案，则先提交的人取胜。
咱们能够把这些事务逻辑都扔到一个函数里，函数只需回来取胜者的姓名给咱们就行。
我正是“有过 Web 编程经历”的人，曾声称全栈工程师 : ) 所以我最早想到的计划也是这个。
和大多工程师相同，我刻不容缓想在这个新项目中运用最近感兴趣的技能，假如能全部用上我就更开心了！
关于完结这个年会游戏项目，尽管我对过去把握的技能有十足把握(诸如 Bootstrap、Vue、Flask、Django 等)，并且知道用时会更短，挑战和 Bug 都会更少，但不知怎么搞的，我脑子告诉我说, 用新的玩意儿！最好用 Hacker News 上被火热评论的结构，退而求其次，也得用近期 Github 上热门的。看起来越酷的越好，假如它的主页上说其时领域的东西都很傻，所以作者在他周末时间做了这个新项目，来拯救可怜的程序员，天啊，我肯定就选它了！
这正是我喜欢把《小飞侠彼得潘》引荐给跟我相同有黑客精力的朋友们的原因, 由于书里说:
最简略的方法是，等海盗脱离后再去救她，可是他这样的一个人，做事历来不必简略的方法。
过了几天, @Caven 给我发信息说:
种瓜 有空记住做一下那个平均数一半的那个游戏的网页哦 感谢
其时，我还沉浸在挑选哪个新结构的纠结里。
我很想运用 Phoenix LiveView 来构建实时后端，由于最酷的那一群黑客现已这样做了！我也想用 FastAPI, 由于 @hidaris 曾给我引荐过, 他已将其用于 thingtalk，Python 社区对 FastAPI 的反馈也适当好。
至于前端，我想用 htmx，它让我重新回到超文本的简略性里，而不是在一个项目里来回耍弄好多门言语。但我也想用 Svelte，由于它告诉我模版代码是不必要的邪恶，而不像托马斯潘恩眼里的政府那样。
政府即便在最好的情况下，也仅仅一种必要的恶，而在最坏的情况下便是一种不可忍受的邪恶 — 托马斯潘恩《常识》
尽管大卫格雷伯或许并不这么看 :)
突然之间，我有了一个绝妙的好留意！ 为何不在前端运用 htmx，而后端运用 Smalltalk 呢，这简直或许开启 Web 编程的新纪元！很可惜，我 Google 了一圈， Smalltalk 社区似乎还没人这样想, 这不正是我的时机吗？ 只不过我得从零开始罢了。所以我在犹豫是不是要为 Smalltalk 社区构建一个新的 Web 结构。想到这些，我差点就跟 @Caven 说，本年的年会程序我来不及写了，咱们后年再玩这个游戏怎么？ 由于我没法在年前完结 Smalltalk 和 htmx 搭档的新 web 结构。
苍天在上，这是我其时切切实实的所思所想，并不是胡编出来取笑大家。工程师有时候交给产品困难，其或许原因之一便是我上头的心路历程，但表现出来的症状是这个:
啊这个功用短期内咱们无法完结上线。
当然，在东西箱里不停纠结也是识别一个优异工程师的小技巧，由于 Ta 热爱这些东西！如 Alan Kay 说的。
堕入到一种与东西的浪漫之中
这浪漫假如过火，就或许引起争端，vi 和 Emacs 用户长达数十年的圣战便是如此。我曾是一位忠诚的 vi 用户，运用了它超过 5 年，为了运用一个文本编辑器，严肃且认真地读过 vi 相关的书(《Vim 实用技巧》这本书写得真不赖)，以便于让手的速度快过脑子，但事实证明这快出的速度用途不大 :) 直到了解 Alan Kay 和个人社区对计算机的观点，我才彻底与 vi 决裂。我现在有点难以置信我曾经在 vi 注入的热情，正如许多浪漫关系相同，事后总会让人有点难以置信。
吃自家狗粮
在 IT 业界这句俚语或许最早是于 1988 年开始运用的。其时微软公司的高级主管保罗马瑞兹曾写过一封题为“Eating our own Dogfood”（吃咱们自家的狗粮）的邮件，在邮件中他向微软局域网管理东西项目的测试主管布莱恩瓦伦蒂尼提出“进步内部运用自家产品比重”的挑战 — 维基百科
@Caven 的信息让我如梦初醒。
种瓜 有空记住做一下那个平均数一半的那个游戏的网页哦 感谢
我决议含泪放弃我那些新鲜玩意儿，先做出一个可用的原型交差。@Caven 觉得假如能尽量运用咱们自家的产品做就更好了。
是呀，为何不必 Scratch 呢！
这不仅或许是最快的方法，它也使年会游戏能够称为一个实在的教学事例，甚至成为一次产品宣传！
更棒的是，一旦这样做，我只需求完结最小原型，@Caven 和其他参加这个项目的人，就能够敏捷加入了，他们能够在 Scratch 里设计出有趣的游戏动画和彩蛋等东西。事实证明，这样做作用好极了，@Caven 甚至在 Scratch 里做了很棒的计算和数据分析！用于游戏开奖环节。
一旦有了激动人心的主意，写代码是适当简略的，究竟编程仅仅表达主意的方式，Alan Kay 让我意识到，大多数人（当然包含我）在编程中遇到的困难都是由于不了解自己在做什么。这正是 Debug 不或许被自动化的原因，杂乱的的 bug 都来自脑袋。人工智能对此也不会有作为，假如你的作业能够轻松被 AI 替代，仅仅说明作业中包含的思考很少（仅仅重复某种模式或转移结构化的知识）。
我当晚回去就完结了可用的原型，成果证明这个结构适当健壮、可扩展和优雅。
这个 Scratch 程序充当抽奖程序的后端，是的！彻底运行在浏览器里的后端！后端并不一定要运行在服务器上(那是适当狭义的概念) :)
我很喜欢这些程序，它模块化、明晰、可了解，并且适当简略调试，你能够实时观察运行期间的每个变量。
我甚至为它构建了客户端模拟器！这样在客户端构建出来之前，就能够开始调试后端了。
模拟器能够用来模拟实在的用户提交数据， 这让算法调试和检验变得极为便利:
这个项目是前后端分离的，假如你看一眼代码会发现，咱们采用消息(MQTT)进行前后端通讯。运用消息非常简略解耦体系，这是 Alan Kay 一直以来的忠告。
当然，咱们尽能够在另一个 Scratch 程序里完结客户端，但我保留了最后的顽强, 运用新东西: replit ! 我有把握用一会儿功夫在 replit 做出 web 客户端并部署上线，由于底子不必部署！
前端要做的事情适当简略，只需预备一个表单，让用户能够填写 Ta的姓名和猜的数字，然后用MQTT发给后端即可。
没运用 Scratch 的另一个考虑是，检查和修改 Scratch 非常简略，并且同事们都很了解，为了防止恶作剧，需求在后端构建很多的防御性代码，那样会伤害项目可读性（咱们将来或许会把这个实在项目用作教学事例）。
我在里头运用了两个有趣的前端库:
- purecss
- MQTT.js
源码在此: happyNewYear2022
@Caven 拿到这些原型后，非常满意，他将这些原型改造为真实有趣的年会游戏项目, 我代他将这个项目共享到了 CodeLab 社区.
想阅读更多相似文章，欢迎关注 我的博客
参阅
- 年会猜数字原型
- 年会游戏最终版
- 猜数字游戏的最佳战略是什么？
