从上班到现在，在单位边看边写也折腾了一些代码了。作为一个有成百上千个 API 的后端项目，整个项目的 API 风格从十分原教旨主义的 RESTful 到看起来是 RESTful 实际上是 RPC 语义的都有。然而在实现需求的时候我越发发现，凡是那些十分原教旨主义的 RESTful API 我都能快速理解并掌握如何使用，而那些 RPC 语义并且在 URL Path 里充满着五花八门动词的 API 往往理解需要花费相当的难度。
长期以来至少在我的周围似乎都充斥着一种论断：「RESTful API 设计起来很别扭」，更有人会直言「
本篇文章首发于 TeaCon Blog：https://blog.teacon.org/shaders-and-framebuffers.html
本文基于：
读者可以在这里下载到本文的源代码：source.zip（56.
Forge 在高版本（Minecraft 1.13+）为事件总线添加了使用 Functional Interface 监听事件的方式。以下是接口声明：
<T extends Event> void addListener(Consumer<T> consumer);
我们可以注意到，我们不需要向 addListener 方法传入一个额外的 Class 代表事件的类型，也就是说事件类型只能通过我们传入的 Consumer<
从 Minecraft 1.13 开始，Forge 不再自带 Scala 标准库作为依赖（作为一个 Scala 吹，这让我很不爽），但 Forge 也为 Scala 提供了一个名为 Scorge 的解决方案。
Scorge 这个项目相当低调，虽然我很快就从 GitHub 上找到了 Scorge 的源代码，但我翻遍了 CurseForge 都没有找到 Scorge 这个
欢迎来到整个系列教程中最难的一讲。本讲将侧重于介绍如何为传统意义上的导线实现能量传输。
和现实世界不同，在游戏中实现传统意义上的导线，要比无线充电等其他实现方式困难得多。因此读者如果实在无法完整实现传统意义上的导线，那也可以退而求其次，去实现其他的能量传输形式。导线之外的能量传输形式往往也是会受到玩家欢迎的。
一个最朴素的想法是让每根导线每 tick 都将附近导线的能量传输过来。实际上一些 Mod（比方说 RailCraft 等）也正是这么做的。
但这样做无疑从游戏体验上就存在一个问题：如果是一根长长的导线，那么每 tick 能量自然只能传输一格，如果导线长达几百根，那毫无疑问需要数秒甚至十多秒的时间才能将能量从一头传到另一头。如果考虑到游戏性能的话，问题更大了：所有的导线都需要每 tick 更新一次，那势必导致世界上每