开年，直接来一场 Tubi-a-thon！
本届 Hackathon 和往年一样：鼓励大家积极参与开源项目，因为 Tubi 有众多服务和工具从开源社区获益，期望能有机会回馈社区，共建共荣；鼓励同事们将平时工作中一些大胆新奇的想法，通过大张旗鼓地招揽队友，付诸代码，变成行动！
和往届不同的是，本次 Hackathon 安排在 Tubi Beijing Team 基本阳康之后，这样的年度盛会将大家再次召集到一起，成为了工作和生活重回正轨的起点，也使本次 Hackathon 有了更多意义。
正如连续参加了四次 Hackathon 的 Tubi 同事所言，“这是迄今为止最成功的一次，没有之一。最大的特点就是人多、好项目多、好点子多，简称三多”。
38 个小组 / 个人参与了本次 Hackathon，完成了 25 个 Demo，其中有 15 个开源项目。既有平时项目中抽离出来的开源工具，也有痛定思痛的创造性解决方案，更有很多产品方面灵光乍现般的改进，令人印象深刻。
很遗憾不能为你重现刀光剑影、创意四射的 Demo 现场，但本文将为你展示其中最为惊艳的四个项目：
Best OSS Contribution Winner：Multi Viewpoint Video Player
作者 Hailong 上线分享
随着 VR/AR 设备的普及，大家的观影模式可能也会随之改变。360 全景视频、多视角视频以及体积视频都有潜在的可能性。出于时间和成本的考虑，我想尝试自己实现一个基于 Web 的多视角视频播放器。
通过这个工程，我们验证了基于浏览器现有 API 实现多视角播放器的可能性，体验了视频切换流畅度，分析了流量与内存消耗，预估了工程化的技术难点。
核心设计
-
创建新的视频容器格式来混合多个视频流
-
多摄像机音视频的同步
-
基于 WebCodec 的多媒体播控
项目代码
“我平时的工作主要是后端开发。Web 开发有很多都是现学现用，时间上不太容易把控；因此选择了一个人 Hackathon，选择以更轻松的心态和更灵活的节奏进行探索。
可能因为视觉效果比较好，所以被选为 Best OSS Contribution Winner，其实很多其他项目在技术难度以及产品创新方面是更优秀的，比如陈天的 Renovate，可以用一种更优雅的方式管理数据库的 schema。得奖固然很开心，但是最大的收获是有机会看到各个领域的优秀创意，激发了灵感，拓展了视野。”
Audience Favorite Hack Winner：Tubi Terms
作者 Chun/Renyu/Yatong 上线分享
随着 Tubi 团队的发展，我们发现大家开始越来越多地使用 Tubiverse（可译为 Tubi 元宇宙）的术语进行沟通，这种提炼和抽象的语言带来了沟通便利的同时，也让一些还不甚了解这些术语的小伙伴有些迷惑，比如 Viewer 和 Visitor 有什么区别，Aha Moment 如何定义。
目前，已有一些简单的解决方案，譬如，有团队在 Onboarding Wiki 列出了一些术语表，也有人用 Google 表格来维护常见的术语。但这些方案或多或少都存在完备性和准确性等方面的问题。
我们期望找到一种更加便于协作、简单可靠的方式来让 Tubiverse 语言真正成为沟通的润滑油，减少同事间沟通的阻力。
方案
在这个工程中，我们实现了：
- 优秀的触达能力
服务的网址简单易记，常用的术语会排列在前面，并可以通过搜索、筛选、标签、引用等方式快速定位；我们也即将支持 Slack 里的链接预览等功能。这些功能点让术语更方便地触达到有需要的人。
- 丰富的表现力
术语支持 Markdown 格式的描述，以及标签等附加属性，便于直观阐释和归类整理。后续我们也计划支持图片等更多表现形式、领域等附加属性，进一步提升内容的表现力。
- 良好的协作性
我们深信这一服务的关键是更多人积极参与，人人共建才会有人人共享。因此在设计阶段，我们就考虑到了一些对贡献者的激励手段。每个人都可以成为贡献者，每一位贡献者都会被记录和展示，同时大家还可以对术语进行 emoji 表情等方式的反馈。后续我们也会在这方面持续迭代。
Demo 时间！
“应该是大家对这样的产品渴望已久，尤其是一些入职时间不长，还在恶补 Tubiverse 语言的新人们。Demo 一结束，就有几位同事联系我们，表达了强烈的共鸣。
最后能拿到这个奖当然非常开心，但更让我们欣慰的是，它不仅仅是一个作品，而是一个可以孵化出来逐步发展的产品，现在已经在 Tubi 内部上线使用啦。当看到这个 Feature 被大家所需要，自己也更有成就感，更有动力去做得更好。”
据说， Tubi Terms 的其中两位成员，在本次 Hackathon 中都有两个项目要赶工，压力之大别提了，但是两个项目竟然都完成了！真真切切地感受到了 Tubi 工程师同事对代码的强烈热爱。
Audience Favorite Hack Winner：What I should Watch
作者 Sara/Paul/Zijia 上线分享
我们发现，新老用户会浏览 Tubi 首页以找到他们喜欢的视频内容，当没找到时，他们也就不会点击观看了。
当用户在主页的浏览时间超过 x 秒时，我们希望能关注到他们，并主动帮他们找到想观看的内容。我们创建了一个 AI 助手来帮助用户找到想看的视频，还挺有趣的。
在 Demo 环节，这一项目确实是反响热烈，这是我们没有预料到的。
我们小组的三位同事是远程协作的，为了有效地合作，我们通过定期 Zoom 会议，将进展进行整合，并讨论解决了我们遇到的问题。这样的协作方式也是我们在 Tubi 工作中一直沿用的。
Editor’s choice：KubeScript
作者 Junjun/Maosen 上线分享
这个想法源自我们日常开发中使用 Kustomize 的痛点。当时灵光一现，想出了一个更简单的方案，于是自己实现并开源。
痛点
Kustomize核心要素是「转换器」（trasnformer），也就是将一个 Kubernetes 资源对象转换成另一个，而「补丁」是最常用的转换器。
程序员一般在每个项目中编写一串基础 Kubernetes 资源文件，然后基于这些文件，针对每个执行环境加特定的补丁。这种设计看起来很简单，但当项目数量变多，或者资源文件变复杂后，编辑和理解这些「补丁」的集合会变得费时费力。例如：
应用根目录下有三个文件夹 base，staging 和 production，分别存储基础 Kubernetes 资源文件、测试环境和生产环境的补丁；每个文件夹下面有几十独立的项目文件夹存储各自的资源。当程序员想要修改某个项目时，需要在这三个主文件夹定位到项目文件夹，并且来回跳转，从众多「补丁」文件中拼凑出最终的资源声明。
基于文件和补丁的方式缺少抽象与复用能力，因此添加新应用时，程序员一般会复制另一个应用的文件，然后再修改；这种复制粘贴的方式既费时又易出错。
Kustomization 声明文件可以引用另一个文件，并且将它当作补丁用来修改其它资源文件。这样层层嵌套，最终的声明对象是由一个「补丁」树逐层修改得来的，可想有多复杂。而且编辑器不支持跳转到被引用的文件，因此想理解整个「补丁」树更加费时费力。
总之，Kustomize 的设计不适合于多团队多项目的大型编程。
方案
Kustomize 本质上是在 YAML 文件格式的基础上设计了一个领域内语言（DSL），用来表达更加复杂的操作；而我们直接选用一个成熟的语言 TypeScript。它的表达力足够好，程序员也不需要学习新的领域内语言；更重要的是，优良的模块设计，使它很适合大型编程。
核心设计理念
-
大道至简
-
摒弃黑魔法（Hack）
-
不重复造轮子，站在巨人肩膀上
项目代码
加入 Tubi
一句 “Enjoy and Have fun” 鼓励了一批又一批热爱代码的工程师，毫不犹豫地加入到 Hackathon 中，只管去做，享受代码的乐趣！
但是，当你完全投入在 Hack 中，拼尽全力完成了项目，超越期待的回报自然而来：参与本次 Hackathon 的中美同事均收获了 2023 Tubi-a-thon 战袍一件，获胜成员还收获了丰厚的礼品卡 🎉🎉🎉 欢迎你，加入到 Tubi 高效工作、品质生活的队伍中来 tubi.tech/careers/
Tubi 有更多
