2020中文学生开源年会 讲者系列专访之三：Nova&Benny&Keshane

2020中文学生开源年会 讲者系列专访之三：Nova&Benny&Keshane

 

2020中文学生开源年会将于10月18日以线上方式举行，在本次活动之前，开源年会组委会特别推出讲者系列专访：从即日起至10月18日，我们将为每位讲者推出一篇独家专访。

记者专访

记者：

非常感谢各位能够抽空参与我们的采访，请问各位能先做一个简单的自我介绍吗？

@Benny：

这个问题啊，很难回答啊。自我介绍这种东西是最难说的了简单的说，我是：一位不知名博主，热爱开源与自由，菜，社畜一枚，已经是老叔叔老阿姨了。

@Nova：

是一个喜欢折腾的菜鸡开发者，写代码能力不怎么样，鬼点子特别多。

@Keshane:  

又到了我最讨厌的自我介绍环节，我是一个菜鸡开发者，刚刚成为社畜，老二次元了。

 

记者：

​各位演讲的题目是：WebP Server Go,请问各位能向我们的读者做一个简单的介绍吗？

@Benny：

有请我们的总设计师Nova来介绍一下！

@Nova：

WebP是一种同时提供了有损压缩与无损压缩的图片文件格式，目标是减少文件大小，但达到和JPEG格式几乎相同的图片质量。生成单张 WebP 图片非常简单，批量转换也没太大难度。但是如果让点的图片可以无痛地以 WebP 格式输出，比如我们的博客上有 100+ 张图片转换该如何操作呢？部分云服务商提供了转换服务，对于个人站点而言，为了同样在不改变站点原始 URL 的的情况下将图片压缩 WebP 格式输出，做到节省流量+提升页面加载速度的效果，WebP Server Go 应运而生。

使用 Go 编写的 WebP Server 是一个单一的 binary，性能优异，并且可以无缝转换JPG/PNG为webp。只需要一次配置即可在不改变 URL 的情况下将站点图片以 WebP 格式输出，唯一改变的只有 content-type 和 length，无痛加速站点。原来下载10M的图片要花10秒钟，使用WebP Server Go ,只需要一秒钟就够了。”

 

记者：

在浏览了各位在博客上发表的 “让站点图片加载速度更快——引入 WebP Server 无缝转换图片为 WebP” 后，我的个人理解是各位复现了的Cloudflare所提供的Polish功能，并将其开源，请问是这么一回事吗？

@Nova:

对的，最初是阅读到了朋友 BlueCocoa 的文章之后开始有了将站点上的图片转化为 WebP 输出的想法，由于不想手动处理图片转换，所以需要有一个在不改变 URL 的情况下直接输出 WebP 的功能，在调研的过程中发现了 Cloudflare Polish，由于 Cloudflare 是一个中心化的平台，考虑到有很多场景下我们没法使用 Cloudflare 或者希望对这个转换的过程有一个更加可控的部署方案，所以开始有了这个 WebP Server，慢慢我们发现这个需求可能不少人都会有，于是就把它开源了。

@Benny：

其实Nova还有一个想法，Cloudflare提供的那些Pro、Enterprise才有的功能，咱都想给复刻一遍。

 

记者：

各位当初选择Go语言除了在性能上的考虑外，请问还有一些什么其他的原因呢？以及请问Go在这个项目上的表现是符合预期的吗？

@Nova: 

最初是用 Node 的 Express 写的 WebP Server Node，之后开始自学 Go 之后打算通过一个实际项目开始学习，就尝试用 Go 写了 WebP Server Go 的初版，当然，写的很糟糕啦，后来有了 @BennyThinks 和 @muzi 的加入之后，慢慢 Go 版本的功能也越来越多了，关于性能部分的话，有请 @BennyThink 来回答。

@Benny：

选择Go的原因，从我的角度来说，第一个原因是Go具有非常强的交叉编译能力，进一步说，我觉得也是Go的最大亮点：Go编译出来的程序，本身就只有一个单一的二进制文件，几乎无任何依赖，什么pip install、npm i根本不需要，拿了就能跑。你看，对你的OS一点污染都没有，不想要了？直接删文件就好了。

并且，理想情况下Go可以直接跨平台、跨架构交叉编译，一台Mac直接就能编译出arm64的Linux的二进制文件——甚至都不用像C那样安装交叉编译的toolchain。这一点就已经非常优秀了。

第二个原因是，Go的性能很好，非常接近C/C++，原生支持并发，自带了很多网络相关的标准库。本来这个东西就是用来提高网站图片的加载速度的，此时如果在因为语言的性能限制，导致速度反而变慢，这不就惨了嘛。因此，用Go来开发高性能网络服务程序是非常适合的。

还有一个隐性原因，说出来怕让人笑话，用Go拿来练手。

第二个问题，从使用者的角度上来说，我觉得是符合预期的。同样也是一个单一的几乎无依赖的二进制文件嘛，用户大概率是感受不出来什么差异的。

但是从开发者的角度来看，还是稍差些的：目前并没有任何使用Go实现的WebP encoder，因此目前也只能使用CGO的方式来使用libwebp的部分代码，这也使得Go的交叉编译能力有些折扣。不过也还可以接受，问题不大。

 

记者：

请问各位认为WebP格式是否在未来将会成为Web图片格式的主流甚至是世界图片格式的主流呢？

@Nova:

我认为会，不过其实未来的方向并不一定需要是 WebP，我们做的是提供一个易用的桥梁，帮助站长（也包括我们自己）优化自己的站点。

@Benny：

高贵的苹果已经在iOS14和macOS Big Sur中添加对WebP的支持了。尤其对于iOS来说，所有浏览器都是使用内建的Webkit，所以对于WebP来说最后一块绊脚石已经开始有被解决的迹象了。所以假以时日，WebP应该会得到更好的发展。

 

记者：

博文中的Afterword中提到了《史蒂夫·乔布斯传》中的一段话，请问各位认为这段话与开源运动之间是否存在某些联系呢？

@Nova: 

「我们很多人都想回馈社会，在这股洪流中再添上一笔。这是用我们的专长来表达的唯一方式——因为我们不会写鲍勃·迪伦的歌或汤姆·斯托帕德的戏剧。我们试图用我们仅有的天分去表达我们深层的感受，去表达我们对前人所有贡献的感激，去为这股洪流加上一点儿什么。那就是推动我的力量。——《史蒂夫·乔布斯传》」

同理，我自认为暂时没有能力能像 Google 一样做出一个规范，让 Web 更快，也没法像 Cloudflare 有一个庞大的网络为众多免费用户提供 CDN，我们能做的是提供一个桥梁，让尽可能多的用户可以无痛地，快速地用「下一代图片格式」来输出站点内容，这就是我们能带来的。

 

记者：

目前许多学生开源项目的开端是同学们的学习过程&自娱自乐，有人认为这样的代码浪费了资源，因为其并没有在某些领域起到了推动作用，只是一堆“死代码”，请问各位是如何看待这样的情况的呢？

@Nova：

我的想法是这样的，学习过程和自娱自乐肯定没问题，但是如果评估一个项目的好坏的话还是需要考虑这个项目是否解决了什么痛点。

举一个反例吧，目前网上有非常多的「博客平台」和「开源后台框架」，外观都看上去非常花哨，Star 也会很多，但是如果我们稍微深究一下：这个项目是否有解决什么痛点，是否完成了其他同类著名项目中没有做到的点，如果以上两个问题都没有一个非常明确的话回答的话，那的确只是一个（可能 Star 非常多的）「死代码」而已。

WebP Server Go 的目的在于「在不改变 URL 的情况下对原图进行转换并输出 WebP 格式的图片」，这一点目前只有 Cloudflare 实现了类似的功能（国内有些 OSS 也有，但是还需要给图片加 Parameter ，显然不是一个「无侵入性」的方案），但是它们没有开源，而且必须使用他们的服务，我们的是开源的。

我们相信在这个小方向上我们的确推动了一些，让整个 Web 变得更快一些了。

@Benny：

如果说“开源”是把代码push到GitHub的话，那么除了自娱自乐等目的之外，还有一个比较少用的目的：备份。

对于大部分人来说，“在某些领域推动发展”这个要求有点太难为人了，但是很多情况下，如果我开源的代码，能够帮助其他人，能够解决一些实际的问题，那么还是多少有些存在的价值。“彼之砒霜，吾之蜜糖”，某些“死代码”也许真能帮到某些不同层次的人呢。

写代码是热爱，写到世界充满爱。我开源，是用爱发电的呀！

@Keshane:

开源项目还是要看是什么目的吧，也不能要求任何人都能够在某些领域起推动作用吧。举例来说，开源领域既有类似chromium这样的大神级项目，也有非常多相似“XXX博客系统”这样的项目，后者对整个行业的推动作用肯定比不上前者，但是后者依然能够帮助到很多人。有许多类似的项目都没有解决太多的痛点，但确实帮助了很多有需要的人，不然也不会有太多的star（买的除外），我认为只要不管项目如何，只要能够帮助到他人，就不能称作“死代码”。

以下通信方式为学生开源年会的官方联络方式，敬请关注。官方网站: 2020zh.sosconf.org
电报英文群组：https://t.me/sosconf
官方微博：https://weibo.com/sosconf
电报中文群组：https://t.me/soscon
中文交流QQ群：738852894

微信公众号：学生开源年会