125 days contributing on GitHub

如果本文有个中文标题,大概会是这样:在 GitHub 上连续 125 天有 contribution 记录是怎样一种体验?

先来简单说说这 125 天里一些自己认为值得一提的事,可能这样大家才可能比较感兴趣地往下看。

这 125 天大致可以分为三个阶段。

开始 #

基本从年假前几天到年假结束,只是出于学习 Elixir 这门语言的原因,需要写点书上 demo 代码。根据我以往的习惯,会把这些代码扔到 GitHub 上,因为这样可能会增加一点 GitHub 的经验值?。当然,这次也是这么做了,不过坚持的还不错,整个年假每天都有看点书、写点代码。

年假过去后 Elixir 的基础学的差不多了,按照之前的习惯,GitHub 的 streak 就又要断了。不过幸好这次并没有,不然就不会有 125 天了。

投入 #

学了一个东西,总要用一下的,不然只是看个书,copy 一些书上的代码,其实跟没学差不多。于是我开始想要做点什么呢,干脆做个网站吧,毕竟 Elixir 还是很适合做 web 的,而且又有 Phoenix 这个比较像 Rails 的框架。于是就花点时间做了一个到现在也没部署、没公开的小网站。这个网站其实不是重点,重点是,做的过程中,我发现 Elixir 生态系统还不太完善。比如,Ecto 有一些可以改进或者 fix 的地方,以及没有能够上传文件到 qiniu 的 Elixir lib。可能这些困难会导致放弃或者想办法绕过去,但我标榜自己是个 hacker 嘛,作为一个 hacker,是应该能够通过更优雅或者更出乎意料的方式解决这些问题的?。

于是我去给 Ecto 贡献代码。虽然我是 Elixir 新手,只能做一些比较相对简单的事情,不过还是学到很多 Elixir 的技能。之后我发现,基本不需要再看 Elixir 语言方面的书了,因为在这些源码里,我能学到更多更实用的东西。而且我的 Elixir 的水平(不包含 OTP 方面)提升得很快,比之前学 ruby 不知道快多少。

于是我写了 Qiniu SDK for Elixir。实现了我需要和我觉得会被需要的一些功能。这个是和写 Ecto 相比很不一样的体验,看上去好像后者更难,但其实自己重零开始写一个 lib,是很不容易的,因为给一个已有的库提交代码时,你有很多代码可以参考,而写这个,我只能参考 Qiniu SDK for Ruby 和七牛的文档了。(这里还是要吐槽一下 Qiniu SDK for Ruby,代码质量不知道有多差,真是有辱 Ruby 语法的优雅,不过还好是 work 的。)而且有很多细节需要去处理,比如怎么安排 lib 的结构、如何测试、如何写文档、如何更好地实现一个 SDK等等。

这个阶段应该是最投入的了,每天除了工作和睡觉的时间基本就完全是做这些了,甚至是周末的大部分时间也是如此。但是也很累,因为从这个阶段开始,我就想能够保持每天都有一些 contribution,而这其实是一件很困难的事情,因为这不比工作,每天那么多时间,而且有很多东西可以做。参与开源项目,能有一个 commit 都不容易,除非那个项目是你自己的。于是我每天至少保证能够提交一个 commit 到 Qiniu SDK ,剩余的时间用来研究和参与 Ecto 的开发。

在这个过程中,也发现 Elixir 的优雅、高生产力、高性能的特点,使我更加喜欢这门语言了。当然,这就是另外一个话题了,完全可以拿出来单独写篇文章了。

坚持 #

直到最近,Qiniu SDK 不断开发,工作上越来越忙,也越来越没有时间投入到 Ecto 中,于是每天至少一次代码提交变得越来越难。所以只能继续完善 Qiniu SDK,比如添加更多的接口、写更多的测试,但是每天提交的代码明显没有之前那样的含量。而 QIniu SDK 剩下的很多功能,其实我是不用的,也就很难保持开始的热情,继续加新接口了。

之所以还这样坚持下去的原因是,Qiniu SDK 确实有些地方可以完善,而且觉得虽然现在有点不容易,但可能稍微坚持一下就会有好转。

最后说一下,为什么选在 125 这天来写这篇文章呢。一来,就像最后说的,真的越来越难坚持下去,索性在还没断掉的时候写了算了。二来,刚好在这个时间点想写点东西而已。

至于之后还会不会继续下去,我也不确定。如果能找到新的东西可以写,可能会。但如果只是为了维持连续的天数,而做一些没有意义的提交,那还不如不做。

 
27
Kudos
 
27
Kudos

Now read this

从 D-state 造成的 high load 到 Erlang 内存分配调优

在 Tubi,我们有个电影/电视剧的 metadata 服务,叫 Content,是一个 Elixir(Erlang) 写的服务。当请求 Tubi 的时候,这个服务会负责把需要的 metadata,比如标题、描述、图片等返回给客户端,是一个比较关键的服务。最近线上因为客户端发送了过多的请求,导致服务器的 (normalized) load 很快地从 0.5 升高到 1.3,同时 latency 升高,最终通过扩容来解决。请求量增加导致 load 升高很正常,... Continue →