Front是一款帮助企业管理电子邮件组(如[email protected])的应用。该应用不但开发了Web版本,还开发了面向OS X、Windows的桌面客户端,他们认为桌面应用有无法替代的好处,并且会被人们重新重视。近日,Front联合创始人兼首席执行官Mathilde Collin解释了他们这样做的原因。

使用Web应用的理由有许多:

  • 一次编码,到处可用
  • 不需要安装,不需要更新
  • Web栈人才众多
  • 让产品看上去更现代
  • Gmail/Salesforce/Zendesk都使用Web应用

持上述观点的人并不少见,但独立的桌面应用有许多在浏览器中几乎无法复制的好处:

  • 桌面应用安装后,如果其快捷方式出现在Windows的开始菜单或Mac OS Dock中,那么它就会一直在那里。而在移动领域,应用不在主屏上,用户很容易把它忘记。
  • 桌面应用可以使用“alt-tab”访问。Alt-tab或许是桌面环境中用得最多的快捷键了。用户每次使用这个快捷键时,打开着的应用(Logo和品牌)就会获得给用户留下印象的机会。
  • 与Web应用相比,桌面应用对下载和预览的支持要好很多,而且可以向剪切板复制内容。
  • 桌面应用访问通知系统更容易,可以更好地发送通知。例如,有新通知的应用在Mac OS X Dock上跳动会更容易引起用户的关注。

另外,Mathilde还举了一个例子。在Front,与使用Web版本的人相比,使用桌面版本的人花在应用上的时间平均要多出34%。但是,这并不意味着所有的应用都需要创建桌面版本。Mathilde指出,这主要取决于紧急程度和使用频率两个方面,如下图所示:

这里所说的紧急程度是指用户需要对正在发生的事件做出快速响应;而使用频率是指用户每天都要在应用上花一定的时间,比如IDE之于程序员,Photoshop&Sketch之于设计人员。如果一种产品既不紧急,使用频率又不高,就没有必要创建桌面版本。

不过,最新技术让创建桌面应用的成本变得非常低,几乎可以忽略。开发人员可以像创建浏览器应用那样构建应用,然后封装到一个桌面应用中,并且能够在任何环境中都提供统一的体验。感兴趣的读者可以点击这里了解Front的做法。

也许有人会问,谷歌为什么不提供桌面应用。Mathilde认为,这是因为谷歌的长期战略不允许他们开发桌面应用。实际上,浏览器端使用减少才真正能够对谷歌造成威胁,而只要用户浏览Web,就会不断地回到google.com。这也可以解释为什么谷歌提供免费的Gmail、免费的Chrome,甚至资助竞争对手

很多不太懂正则的朋友,在遇到需要用正则校验数据时,往往是在网上去找很久,结果找来的还是不很符合要求。所以我最近把开发中常用的一些正则表达式整理了一下,在这里分享一下。给自己留个底,也给朋友们做个参考。

一、校验数字的表达式

自2012年开始,安全公司CrowdStrike就使用Scala开发他们的应用程序,Scala成为其技术栈的重要组成部分。但随着工程师团队由早期的5人扩大到现在200多人,他们决定迁移到Go语言技术栈。近日,该公司云计算工程部门的高级主管Jim Plush撰文阐述了他们采取这一举措的原因。

不过,Jim首先声明,迁移到Go并不是说将Scala从CrowdStrike的技术栈中完全清除出去,实际上,它可以补Go之不足。Scala是CrowdStrike机器学习/分析技术栈的重要组成部分。它可以同该公司使用的Java项目进行互操作,而且能够提供不错的DSL供分析师使用。也就是说,Scala更多地成为一种专用工具,而不是核心开发语言。

作为一名技术负责人,Jim希望代码具有很好的可维护性,开发人员很容易跨项目工作,而新进人员很容易跟上项目的进展。早在2009年尚在其他公司工作时,Jim就开始认识到Scala的扩展性问题。他们遇到了一个本可以几分钟解决的Bug,但却因为编写那段代码的人正在度假而花了几个小时。这说明团队出现了分化。Jim指出,这种分化同Scala语言本身的特点有关。通常,Scala开发人员分化成了两个阵容:一个将其看作“更好的Java”;一个将其视为“Applicative Functors”。前者喜欢Scala的简洁性以及那些让它比Java更惹人爱的标准特性;后者则关注函数式编程。这两种风格没有优劣之分,但确实会导致团队的分化。而且,随着工程团队的日益壮大,这种分化会愈加明显,新进人员要跟上项目的进展就更加不易了。

当然,这不是他们迁移到Go的全部原因。他们还有许多与构建环境相关的痛点,如SBT、IDE环境、构建时间长、JAR包老而大,等等。另外,大量的ScalaZ概念和长时间的前期培训降低了开发效率。据Jim介绍,他们并不是唯一存在这些痛点的公司,Twitter也经历过。因此,他得出结论:

使用Scala,你可以拥有一个非常高效的小型团队,但当你尝试将工程团队的规模扩大到50人以上时就非常困难了。

相比之下,Go存在的其中一个原因就是让开发人员更高效,限制实现方式的种类。在Sean Berry的鼓励下,Jim经过深入研究发现,Go可以解决他们使用Scala时在组织扩展层面上遇到的许多问题。Go有诸多优点:构建快、二进制文件小、单文件、更好的工具、内置测试框架、性能分析器、不错的并发模型,等等。他们用Go逐个完成了多个项目的开发,能够使用Go的开发人员越来越多。开发人员加入任何一个Go项目都可以很快弄清楚当前正在进行的工作。使用Go还有一个好处,就是招聘更便利了。他们可以招聘任何语言背景的开发人员,然后进行为期数周的Go语言培训即可。有位起初抵制迁移的高级工程师在做完他的第一个Go项目后告诉Jim:

那个库,我读了一遍就确切地知道它在做什么了,而那个库的Scala版本,我已经读了四遍却仍然不知道它在做什么。我知道你的伙计为什么那么喜欢它了。

现在,CrowdStrike大部分的服务都是使用Go语言编写的。它们每秒处理几十万条消息,每天处理数TB数据。

声明:此文只代表我个人浅浅的认知观点,有任何不妥之处欢迎指正!

本文比较了两岸草根开源社群之间的异同,提出了草根社群共同面对的挑战和压力。也许两岸开源社群深度合作,才能解决这些问题吧。本来计划在9月份完成本文,却先后因为个人的感情变故、工作转变和亲人生病亡故一直拖到年底。

两岸开源社群面面观

(题图来自: juancoccaro.com)

2014 年参加完台湾 COSCUP 以后我写了《两岸开源文化面面观》一文,在两岸开源社群中引发讨论。甚至还引起台湾出版业巨擘郝明义先生的关注,并在今年9月出版的他的新书《如果台湾四周是海洋》中提到并引用,同时郝先生也亲自参加了今年的台湾 COSCUP 2015。一年后,当我再回头看这篇文章时,难免觉得仍然有些片面,缺少实践考察和足够广泛的了解,还有很多地方需要再来补足。

从 2014 到 2015 这一年,通过各种平台,我不断与对岸的草根开源社群保持联系,持续考察和比较两岸开源社群的差异。今年参加 COSCUP 2015 期间,更是想办法补足之前缺失的地方,特别是与去年没能深入交流的朋友,加深了联系和交流,又与某些“COSCUP-Hater”聊,听听他们的看法。今年不仅与年轻人聊,更与年纪大的人交流,与传统大公司的人员交流,以获取更多”世代”之间的看法。与去年参加 COSCUP 之后对台湾开源社群的盛赞不同,今年我更多了几分理性和开明。也许也与这一年多来我本人心智看法的变动有关系。

COSCUP 2015 的主题是“开放文化”

COSCUP 2015 的主题是“开放文化”

近几年,我更偏重去中心化、草根化的社群治理,所以这次去台湾完全只关注草根社群,已经不再丝毫考虑其他组织形式。决定在去年《两岸开源文化面面观》一文的基础上,再写一篇《两岸开源社群面面观》。

散兵游勇 VS 自治共荣

大陆的草根开源社群,很难有形成规模,形成社群优势的。即便是我参与的北京Linux用户组(BLUG)也无法很好的发挥社群优势,这与社群成员闲散,社群整体偏向自由的风格是密不可分的。然而更多的草根社群,则是因为太过闲散,无法组织起有效的开发,或组织新的活动,也就无法产生什么新的价值,大量曾经活跃的社群名存实亡。产生这个问题的原因是,社群成员个人自治能力欠缺,总希望让别人来帮忙,没有意识到自己动手治理自己的社群。

参加 Hacking Thursday 和 WoFOSS 联合举办的活动

参加 Hacking Thursday 和 WoFOSS 联合举办的活动

相对来说,台湾开源社群的自治能力很强,成员的自治能力,自我负责的意识也比大陆强一些。这次在台湾恰逢Hacking Thursday 和 WoFOSS 两个社群一起联合举办活动,在参加活动的过程中,我与很多新朋友交流,发现台湾开源社群成员的自主意识比较强,社群自我治理的能力比较强。也就是相对大陆开源社群而言,台湾的开源社群更加成熟,有更多自身的价值,这样就能有稳定的社群文化输出,有更稳定的社群影响力。关于这一点,本文下面会多次提到。

商业导向 VS 社群主导

从成果的角度来比较,这么多年大陆几乎没有在国际上很响当当的,或具有开创性的开源项目,也许可以想起来的是阿里巴巴的 Tengine 比较国际知名,然而却不是一个由草根社群发起或维护的开源项目。OSChina网站收录了 5800 多个国产开源软件,看看有哪些是国际知名或有国际开创性的,有哪些是真正由草根社群维护或主导的。我的意思不是大陆没有国际知名的,像 fcitx 输入法框架、文泉驿字体等等也有一些,真正具有开创性和全球普遍应用的少很多。即便有,往往也不是由草根社群来维护和传承的。

既然没有自己的国际开源项目,那么我们就在现有的国际项目里挤进自己的位置吧。借着民族主义和政府”自主可控“的想法,比如国内某超级大公司(不能说其名字),鼓励公司员工贡献到国际主流开源项目里,或者从开源基金会的成员里挖人,比如 Linux 基金会、Docker 基金会、OpenStack 基金会、Linaro 基金会等等。这家大公司贡献的同时,更利用强大的财力和人员优势,可以从这些基金会中争取到足够的话语权,甚至影响这些基金会最终为己所用,最终可以服务其商业目的,甚至为民族主义和政府的“自主可控”背书!

这次在台湾的一个收获是,听了 LXDE 桌面环境的作者,同时也是 Android 项目的主要贡献者 Jim Huang (黄敬群,Jserv) 的封麦演讲。在演讲中,他回顾了台湾这十几年来开源历程,其中一个个响当当的开源项目,让我知道除了 LXDE 和 PCManX 以外,还有那么多国际知名的开源项目,比如 CLE(中文化的Linux桌面)、Open Webmail,Firefox OS(台湾主导),MCLinker(LLVM 链接器),uming/ukai 自由字体……而这些几乎没有大公司的主导或者影响。

黄敬群在 COSCUP 2015 的封麦演讲

黄敬群在 COSCUP 2015 的封麦演讲

草根社群基于兴趣开发的开源项目,在大陆并不是没有,最终往往还没成气候就死掉,或者被大公司收入囊中,亦或者封闭起来自己创业,沦为商战炮灰。在商业大潮中,我们需要涌现更多由草根底层社群维护的开源项目,这需要从社群治理到项目管理等多方面共同入手和改变。

学校领导 VS 学生自治

草根社群的一个重要组成和人才来源就是学生社团。自从去年在 COSCUP 上知道了台湾的 SITCON(学生计算机年会) 之后就一直很关注此组织的发展和其活动方式,我还曾观看 SITCON 2015 的在线直播。 除了办会,还在这两年推出了夏令营,社群讨论会等等多种活动形式。在我看来,像 SITCON 这种跨学校间的大范围社团联盟组织,具有非常强的生命力和社群影响力。今年 COSCUP 2015 上,无论是学生志愿者还是演讲者,很多都是 SITCON 的成员。他们在传播开源理念,传递贡献精神和参与意识上,付出了巨大的努力。

SITCON 在今年香港开源年会上的演讲,SITCON 现已发展到香港

SITCON 在今年香港开源年会上的演讲,SITCON 现已发展到香港

中国大陆没有一个跨学校间的社团联盟组织,即便有也会被取缔或者被党团收编,强力管控起来。很多高校都有自己的开源社团、Linux 协会等组织,绝大多数都在学校党委、团委等领导的强力管控之下,活动自由受到极大影响,更不可能有丝毫的社团影响力,难以在学校中吸引到学生群体的注意。更有些社团组织在学校的影响之下,变成了创业推进社团,完全走向了逐利。不过也有一些夹缝生存的社团组织,他们尽其所能创新活动形式,引入适宜学生的开源项目,引导学生进入开源贡献的队伍。这其中的佼佼者如中科大的 USTC LUG 和清华大学的TUNA 协会

根据几年前我的观察,发现社团里的学生群体普遍缺少自治能力、自我约束和自负其则,这一点在二类本科和三类本科学校尤为明显。去年我工作过的公司就是利用了学生的这个特点,瞄准差一些的学校学生,急于追赶且忧虑就业的心情,向学生群体灌输“开源即免费分享”、“开源贡献=大公司敲门砖”的思想。这种做法虽不能算错,但让学生群体如此“利欲熏心”,是非常不利于学生自治能力提高的,更不利于草根开源社群的构建和发展壮大。

草根开源社群的挑战

无论大陆还是台湾,草根开源社群面临的挑战都有出现,且日益严峻,这些挑战每一个都影响到社群的生存和发展。下面仅就我观察到的社群挑战,说说看法。

青黄不接的代际传承

很多开源社群都面临这样一个问题,都在担心“继承人”的问题,很多社群就是因为没有人继承而慢慢死掉了。现在面临的情况是新的社群成员还没成气候,老的社群成员就离开了(事业变动,个人原因等等)。即便是北京有像 BLUG 这样从很早就定下代际传承的,也依旧面临青黄不接的问题,深深的担忧。这次参加台湾 TOSSUG(台北开源软件用户组)的活动时,发现他们也同样发愁这个问题,很多时候发现开源贡献者或者参加线下活动的就是那些人,很少见到新面孔。

我和黄敬群

黄敬群(右)和我

如何解决呢?11月来黄敬群北京,参加活动并和 BLUG 一起聚会聊天。他一针见血的说到“开源社群需要更‘开源’”(广开源路),需要社群更多包容能力,需要拓展更多的渠道,也需要积极培养新手的成长(这正是黄敬群现在台湾做的事情)。在大陆草根开源社群的生存空间和渠道很窄,这就限制了发展的能力,加之社群能力有限,发展困局非常严重。我依旧会在 BLUG 多作尝试,探索社群治理的新模式,努力开拓更多渠道和生存空间。

中心化的压力和诱惑

另一项挑战是大公司看到开源社群的价值以后,希望“招安”。有人会说,这样不会很好吗?但这样会牺牲掉社群的独立性和轻利性,会进一步削弱自治能力。对缺少自主能力的人,大公司的诱惑力很强的。黄敬群在今年 COSCUP 的封麦演讲上直言:“本来你就可以自己改,不要沦落为某些商业公司的‘抬轿者’”。比如国内某 Linux 发行版,最后就是创业并走入政府热门行业“国产操作系统”,甚至为“自主可控”的民族主义背书,实在让人唏嘘不已。

我本人是非常看重社群自治和自主能力的,可以参考今年5月写的文章《开源社区最需要什么?》

经济价值的转化

面临挑战,同时也蕴藏机遇。草根开源社群虽然轻视经济利益,但如果能有很好的产品,显然对其自身发展有极大的帮助。今年台湾 Ezgo 团队带我一起拜访了 Banana Pi 的设计者洪宗胜老师,顺便参观了他的工作室。Banana Pi 是洪宗胜老师和深圳的开源硬件社群一起完成的产品,非常成功也有极大的影响力。目前还有很多芯片厂商希望与其合作。

Banana Pi 的设计者洪宗胜老师

Banana Pi 的设计者洪宗胜老师

同样,还有脱胎自 COSCUP 的 “CPR 线路组”,成功创业承接会务专业布线和网络架设的业务。

“线路组”和 Bnanana Pi 的成功并不是孤立的现象,这背后既有社群治理的成功,同时也有敏锐捕捉市场需求的能力,最重要的依旧是踏实奋进,自主创新的实干精神。我们不需要天天混吃混喝,聚会打嘴炮吹牛逼的社群,我们需要能够创造交流合作机会(如 SITCON 和 Hacking Thrusday),或有能够产出具体成果(如“线路组”和 Banana Pi),或者可以主导和维护有国际影响力开源项目(如 LXDE)的草根社群组织。

跨越海峡的开源社群合作

我在《两岸开源文化面面观》一文的结尾发问“一弯浅浅海峡隔开的是什么?”,呼吁大陆可以通过开源社群的发展,进而推动社会文化进步。一年过去了,草根开源社群的非但没有发展,反而大跨步退化。自治能力丝毫没有提高,开源社群一个个倒掉,或投入大公司和政府的怀抱!

大陆和台湾的草根开源社群,面对的挑战是相似相同的。台湾因为成员有相对较高的自治能力,社会环境比较自由(主要是互联网),解决问题也许会容易一些,社群治理会简单一些;而大陆的优势则是机会比较多,资本相对集中,适宜创业开发。既然如此,大陆和台湾的草根开源社群完全可以合作,共同建立跨越海峡的开源社群,推进开源在两岸间的双向落地。我相信草根开源社群,也就是去中心化的社群合作,要比其他方面的合作更容易,因为年轻人之间有相似或相同的文化,对去中心化的社群治理有广泛的认同,大家对真正的开源精神(黑客伦理)也有更多的共识——这是真实存在的共识,不是“没有共识,强说共识”。

郝明义先生的赠书

郝明义先生的赠书

我希望两岸间的开源社群合作,可以遵循“自由自治,相互尊重,草根融合,联结共荣”的原则。每个社群应懂得“自己的社群自己治理”;社群里的每个成员也应自负其则,切实负起发展自身社群的责任。同时社群和社群、人与人之间也应该尊重彼此社群的特性,尊重对方选择的社群发展路线(比如创业或停掉)。同时我希望的是底层草根之间的融合与合作,而不涉及企业商业公司社群,甚至政府部门;只有草根社群之间才有可能对真正的开源精神(也就是黑客伦理)有较多的共识,才有可能深度融合与联结。最终达到两岸开源社群的共同繁荣。为何我要提出这十六字原则,也与这一年来我对开源社群治理的看法有关,我认为只有自治才能共治,只有自私才能无私,只有自由才能共荣。郝明义先生在《如果台湾的四周是海洋》一书中说“要敢于和对岸合作”,这句话不仅说给台湾人,也说给大陆人。合作才能创造价值,闭门造车最终只会毁了自己。更何况,开源精神的本质,就是通过促进人与人之间的联结,创造更大的价值。

2015 年是 COSCUP 的第十年,十年来 COSCUP 为台湾本地的开源推广和开源发展,推进人与人之间的联结,社群之间的合作,作出了不可磨灭的贡献。展望 COSCUP 2016,即将到来的 2016 年将会开启 COSCUP 的“后十年时代”,这里我斗胆提个不成熟的建议:不妨将 2016 年 COSCUP 的主题定为“两岸开源社群合作”吧。我衷心希望两岸开源社群可以加深合作,互通有无,互相融合,让 2016 年成为两岸开源社群合作的元年。

感谢200多位志愿者的努力,让此次 COSCUP 如此成功

感谢200多位志愿者的贡献与付出,让今年 COSCUP 如此成功

对于Twitter这样的基础设施规模,硬件和网络错误是不可避免的,但无论是哪一种错误都可能对用户体验造成消极的影响,因此对一个系统而言弹性的错误处理能力是非常重要的,那么Twitter是怎样做的呢?最近Twitter基础设施工程团队的负责人Mazdak Hashemi在官方博客上发表了一篇文章,介绍了 Twitter的故障测试机制

为了测试服务如何响应异常,Twitter创建了一个能够将受控的故障条件注入到基础设施中的框架,通过该框架Twitter能够发现漏洞,从而更好地为全站范围内的事件处理做好准备,保证系统对意外故障具有较好的容错性。

框架

Twitter的故障测试框架由一个Python类库和一个命令行可执行程序组成,通过该框架工程师能够将故障条件直接引入到产品基础设施中,然后能够在测试执行期间监控全站范围的健康指标,并在状态发生变化的时候发送系统通知。

该框架包含三个模块:

  • 故障引入(Mischief)模块,在产品服务和基础设施中引入或者撤回故障测试
  • 监控模块,检查服务的健康指标,查找可能导致全站范围事件的状态
  • 通知模块,与HipChat和JIRA等系统交互,在故障测试执行期间提供实时的状态更新

到目前为止,框架支持的故障条件包括:

  • 发送命令给IPMI控制器和PDU的功率损耗
  • Mesos中服务集群的部分或者全部丢失
  • 推送新转换配置造成的网络丢失

下面是一个介绍工程师如何使用框架测试故障条件的示例,该示例为abc机架上的所有Hadoop DataNode引入了一个30分钟的功率损耗,然后监控健康指标并向聊天室发送状态更新:

failure_test:
  name: Power loss within rack abc in datacenter abcd
  duration_mins: 30

  mischief:
    - power_loss:
        datacenter: abcd
        selectors:
          - group:
              type: role
              name: hadoop.datanode
          - group:
              type: rack
              name: abc

  notifiers:
    - chat:
        rooms:
          - Failure Testing

  monitors:
    - observability:
        datacenter: abcd
        queries: !snippet

将这些配置发送到框架的命令行工具上之后,框架首先会解析这些配置,确认其有效性。接下来框架会进入准备阶段,收集引入故障条件所需的所有信息,例如目标机器的主机名和IPMI BMC接口的地址等。准备成功之后,框架会检查需要测试的所有系统是否健康,并尝试引入请求的故障条件。如果条件引入成功,框架就会定期地(每分钟)检查监控,确保测试期间所有系统都运转正常,如果这期间有任何一个监控发送了错误的状态,那么测试就失败,否则测试就成功。但是无论是成功还是失败,框架都会在测试执行完成之后立即取消引入的所有故障条件。

完整的流程图如下:

挑战

Twitter运行的基础设施具有异构且动态的特性,所以在为一个具体的服务引入故障测试时需要细心的设计和计划,考虑要全面。例如,托管在Apache Aurora上动态调度的服务与直接运行在硬件设备上的服务不同。为了找到引发异常的真正原因,必须捕获完整的测试环境,包括机架配置、服务类型以及流量等信息,因为在某些情况下,异常可能是由上游或下游的问题,或者是服务恢复行为引发的。

使用情况与经验教训

在过去的6个月,这一框架驱动了Twitter所有的故障测试,帮助Twitter发现了大量的漏洞,让Twitter对Apache MesosApache Aurora等主要系统的弹性故障处理机制有了非常强烈的信心。

另外,Twitter还总结了一些经验教训。例如,从机架顶部开关损坏的故障中总结出:当这种情况发生的时候,运行在该机架上的服务要么全部从网络上丢失,要么丢失部分包,对于前一种情况Twitter的服务能够很好地处理,但是后一种情况却几乎总是会造成某些内部的影响,这种影响的严重程度取决于机架的配置和Mesos从机上运行的服务种类。

未来的工作

Twitter将继续使用该框架测试基础设施对随机故障的处理能力,找到系统的瓶颈。同时,故障测试程序的范围也会增加,将来扩展RPC系统层也将支持这种机制。