写在流利说 Hack Week 之后

这周公司内部搞了为期一周的 Hackathon 活动,有十几支队伍参赛,很是热闹。

Hackathon 对我而言并不陌生,从大学起已经参加过三次 24 小时的,参与举办过一次 48 小时的。几乎每次参加 Hackathon 都会让我见识到很多牛人,也让我受到很大影响。

刚开始听说 Hackathon 就觉得很神奇、很让人热血沸腾,要在 24 小时完成构思、组队、开发、准备演示等全部的工作。粗想一下会觉得这怎么可能,但又让人按捺不住想去试一试的欲望。

第一次参加的景象还历历在目,它并不像现在很多的 Hackathon,有各种赞助商、高大上的场地,只是几个大学生发起的、面向大学生的,大概有二十个人参加,所有人都挤在一个可能还不到一百平米的住房里,待了一天时间,几乎都没怎么睡,就为做出一些东西。记得有几个师兄做了一个 web 上提交代码,然后返回编译结果的网站,对于当时基本不懂 web 开发的我,觉得这真是酷毙了。而我和另外一个朋友则用 C++ 写了一个 Windows 上类似泡泡堂的游戏。

除此之外,Hackathon 很有趣的另一点在于,因为很可能要和一些不认识的人组队,而大家的技术栈也不尽相同,所以经常需要快速学一个技术,然后马上做出点东西。虽然在时间本来就很紧张的几十个小时内还要去学个新技术,但因为目标明确,也倒挺有意思,而且经常有其他人带,所以很快就能上手。

从 Hackathon 也能看出技术的演进和趋势,开始是 Web,然后移动开发,现在则是各种硬件、人工智能,大家使用的编程语言也在不断变化。

公司的 Hack Week 跟以往的 Hackathon 差别其实很大。最明显的是时间长了,提前就可以想 idea、组队,最后有一周时间开发。这意味着不用拼命熬夜了,毕竟是持久战,但似乎也少了一些紧张感。想法可以更完整、成熟、目标性也更强,但也容易“想得太多”,而且少了一些说干就干的快感。因为是在公司内,大家都很熟悉,所以合作也更容易、分工也会比较明确,不过可能也少了更多思想的碰撞,少了一些向外部学习的机会。有更多的时间可以把作品做完整,但同时要求也会变得更高。

虽说如此,但因为每个队创意不同、组成不同、风格不同、时间不同(因为有时还是要处理公司的事情),所以大家的目标可能也不完全一样。

我们队,算是比较稳的风格,一开始就确定要做完,而且要做真正可用的产品。所以把需求分为三类:对展现产品没有帮助的、可做可不做的,就不做;基本的功能,或者是虽然有点难度,但能体现出价值、乐趣的,一定要做;对改善用户体验有帮助,但比较耗时、不确定因素较多的,最后根据时间来决定做不做。

整个过程中还算比较顺利,开始两天比较紧张地完成了基本功能,然后在此基础上完成剩下的部分,最后有一天左右主要用来修 bug、测试和准备 demo。

如果一直都照计划按部就班地完成,那估计会挺没意思的,于是就发生了一些计划外的有趣的事情。本来待定的 push 功能,中途因为自己用起来觉得实在太不舒服,决定改成必做的。也砍掉了一些开始讨论要做的功能,或者是进行了改造。最后两天,还做了简单的宣传主页,而且开放给公司内测,有意思的是,倒数第二天要结束的时候还根据用户反馈加了修改头像和昵称的功能。push 和小红点的通知,看似是小功能,其实花了蛮多精力去开发和调试,不过也蛮爽的,因为增强了可用性。

而我自己的成长,除了一些产品方面、甚至是推广方面的,技术方面也有不少。虽然对主要开发语言 Elixir 算比较熟悉了,但真正地部署到生产环境,给客户端接入、用户来用,应该还算是第一次(heroku 的 demo 就不算了)。这就意味着,所有生产环境可能会遇到的问题都要在一个新的技术下去想办法解决,从基本的如何自动化部署、配置管理,到简单的查看 log、修改数据,再到一些问题的调试,每一个都是新的挑战。

再说说最后的 demo。因为产品完成度还算不错,所以还算是比较顺利,把特点基本都展示出来了。虽然没有拿到大家很想要的第一,不过第二也还算不错,而且仔细想想,确实可以做的更好。

另外,不管是数据、人工智能、社交,甚至是纯技术等方面,都有一些很有创意和创造力的作品出现,大家都很有才啊。

期待下次这样的活动 :)

点后边这个链接可以看到这次 Hack Week 的官方总结 Never Stop Hacking!

 
18
Kudos
 
18
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 →