酷 壳 – CoolShell http://www.chinamxjy.com 享受编程和技术所带来的快乐 - Coding Your Ambition Tue, 13 Mar 2018 05:55:18 +0000 zh-www.chinamxjy.com hourly 1 https://wordpress.org/?v=4.9.5 关于我”极客时间“的专栏 http://www.chinamxjy.com/articles/18246.html http://www.chinamxjy.com/articles/18246.html#comments Tue, 02 Jan 2018 08:56:11 +0000 http://www.chinamxjy.com/?p=18246 Read More Read More

]]>
不少朋友都知道我在“极客时间”上开了一个收费专栏,这个专栏会开设大约一年的时间,一共会发布104篇文章。现在,我在上面以每周两篇文章的频率已发布了27篇文章了,也就是差不多两个半月的时间。新的一年开始了,写专栏这个事对我来说是第一次,在这个过程中有一些感想,所以,我想在这里说一下这些感受和一些相关的故事,算是一个记录,也算是对我专栏的正式介绍,还希望能得到、大家的喜欢和指点。(当然,CoolShell这边还是会持续更新的)

为什么要开设一个收费专栏

首先,说一下,为什么要开这个收费专栏。

老实说,我一开始根本就不想开收费专栏的,是的,完全不想!主要是有两个原因,一方面是我在创业中,我自然是没有太多的时间,另一方面是,我以前在《为什么我不在微信公众号上写文章》也说过,我觉得知识最好的方式是被检索、讨论、引用、整理、补充和更新。所以,收费这种模式,我感觉并不利于很好的传播。但是,我为什么还干了这么一件事?这事还得从2017年6月份开始说起。

这个月,一共有三家技术社区来找我,都是希望我能去他们那边开收费专栏,其中一家就是“极客邦科技”。对于这三家来说,从一开始我就是以婉拒的姿态回应的。而“极客邦科技”来找我的时候和我说,一周写五篇,写一年,一共260篇。我当时心想,“去你的,当我啥呢,你们真以为技术文章好写啊”?然后,他们问我可以写多少,我说,我现在也就一个月一篇的节奏……

然后,就开始了时间漫长的拉锯战。极客邦这边一直从6月份和我谈到9月份,完全就是不达目的不罢休的玩法,其间,每当我说一个问题,他们就会想出一个解,我这边不断地制造不能写下去的问题,他们就不断的给出相应的解。我其实是想让他们知难而退,另外,我也不确定这帮人对于这个事有多上心,因为写技术文章是需要非常认真的态度的,所以,我提出了很多比较苛刻的条件,甚至也很直白的直接拒绝,但是他们完全就跟没有听见似的,不断的想新的方法来让我”上床”(对!就是上床,不是上船)。

  • 我说,我最多一个月写2-3篇。他们和我说,我们看过了,你写的都是长文,都在5000字左右,一篇可以拆成上下篇,这样就有6篇左右了,然后,你每个月再来两篇文章,一篇是推荐一些资料或资源,一篇是回答读者的问题。这样就有8篇了,一周就可以发2篇了。
  • 我说,就算是这样,我也没有时间写,我现在创业中,事多得去了,完全没精力投入。然后,他们说,不用你写,我们来帮你写。你去客户那边,叫上我们,你到大会上做分享,叫上我们,你和别人分享,也叫让我们,我们全程录音,然后帮你你整理。然后每周末的时候来找你,和你聊上2个小时。我们把内容做出来,你再精编一下就好了。而且,我们也会帮你分担创业的精力的,我们极客邦/QCon/ArchSummit会帮你的产品做推广、做市场和BD客户……
  • 我说,就算是这样,我也没时间。他们说,我们还会给你配个编辑,一个不够就配两个,他们会帮你上网查资料,他们都是计算机专业的,一定是懂技术的。不会让你一个人写的。专栏这种事一定是会需要一个小的编辑团队的。

他们还甚至在晚上10点左右跑到我家门口来和我谈。这还没完,我继续刁难他们……

  • 我说,技术文章相当专业,你们来试试看,于是,我给了一篇极其难读的英文论文,还有一篇技术细节非?;奚挠⑽奈恼?,我让他们不要翻译,而是读懂后理解完用自己的话,能够让一般人读懂的话写一下。这两篇文章,就算是对于有多年经验的程序员来说,也是很难读的。结果他们一周后,就搞好了,我读了一下,不算特别好,但是对于他们来说,已经很不错了。
  • 我又说,我的文章中会有好些代码,有数学公式,在手机上怎么排版?阅读体验不行吧。你们还要做音频,我的文章中如果有代码,有图片,有数据公式,你让音频时怎么读?这不行吧。他们说,数学公式可以用LaTeX搞,代码排版会努力排好,同时也提供网页端的浏览。音频会这样搞,会让编辑把代码、数学公式、图片理解完后用别外的话说出来。也就是说,文章要有两个版本,一个是阅读的版本,一个是给音频师的版本。

就这样,这几个月的过程中,我心里面有了一些不一样的感觉。

  • 一方面,我觉得这种“不达目的不罢休”的做法让我欣赏。因为我也在创业,创业的过程中有很多难题,也会遇到很多困难和艰辛。而极客邦他们这样的作法我是非常认可,也是非常佩服的,因为,要是换作我,我可能早放弃去寻找其它人了。但是他们没有,他们一直不断地在穷尽一切方法来说服我写专栏。能这样做的人,我觉得这个社会上少之又少,绝大多数人都是畏难和容易退缩的,所以,感觉可以深入交往和合作。
  • 另外一方面,在整个过程中,我问他们,为什么你们要把这个事做得这么“重”?为什么不做得“轻”一点呢?还要录音频,音频对于技术型的文章里面有一堆坑啊,对于技术文章还有很多无法翻译的英文单词,在计算机的世界里,好多英文单词都是造出来的,音频师怎么读?(后来的确也是这样,我的音频师就把J2EE读成了“J二EE”),他们的编辑也不知道怎么读,就上Youtube上找相关视频看老外是怎么发音的,然后标注好。而且,我的文章有时候写得太快,经?;嵊幸恍┬〈砦?,文字好改,但是还要改语音。对于这些,我都觉得好重啊,结果他们说,就是要做个“重的”,就是要做一个别人达不到的标杆,让竞争对手望而却步!

对于这两点,是让我很赞的。这样的做事精神和态度让我很佩服,是啊,在Amazon里也常说,要不断地提高标准。而且这让我深入思考了一下,一个事如果想要做好,做到极致,就算再简单的事,也会变成复杂,这个世界上可能并不存在“轻模式”,只要你想做好,再“轻”的事都会变“重”。他们的这些做法,让我有了一种同道中人的感觉,人总是会向比自己强的人或是跟自己比较像的人靠近的。我感觉我在创业路上,就是要和这样的人在一起,面对再难的事,都要想尽一切办法解决之,面对再轻的事,都要花心思用重的模式去做好。

而其它两个来找我做同样的事的公司,却没有让我看到他们有这样把事做成的不服输的决心和态度,真是形成了强烈的反差和对比。

于是,我就这样“从”了!这里要点名一下极客邦的两个人——我叫他们作“双蕾”:司巧蕾郭蕾。(池大大也为极客时间付出了好多,因为大家都认识他了,我就弱化他一下了,嘿嘿)

这个专栏主要会写什么样的内容

这是一个收费专栏,一旦收费了,我的压力也大了,因为你要写的内容就一定要能达到可以收费的价值了,不以再像个人博客一样,想写什么就什么。好在我从2003年开始我就在给好多企业做一些商业化的讲座和培训,也给一些公司做过一些商业的咨询和技术方案,包括在过去两年内帮助过一些公司打单。另外,在过去的10年内,我也在技术、职业和成长上帮助过很多年轻人。这些内容,我都没有完整或是具体地写在CoolShell中,所以,我觉得这些内容是可以放在这个收费专栏的。

此外,我在CoolShell上的文章都是不系统的,是碎片式的,还有一些只是知识,还不是认识。而我过去成长的20年,我的经验和知识已经在某些方面形成了比较完整的体系,而且有一些技术也能看到本质上的东西。所以,我觉得这些东西是可以呈现在这个专栏内的,都是非常有商业价值的,一定是可以帮助到大家的。当然,其中的一些东西,不是初级入门的程序员能够看懂的,需要有一定的工作经验和基础知识。

而在我入行的这20年来,我觉得对于一个企业,一个团队,一个个体的程序员来说,有三件事是密不可分,也是相辅相成的,这三件事就是:技术、发展和管理。每个人,每个团队,每个企业,都需要认真地面对技术,不断地挑战新的技术,并且还要非常认真地发展个人和团队,而这些都需要对自我的管理或是对团队和公司的管理才能更高效的达成。

所以,我的专栏会由这三部份构成:

  • 技术。对于技术方面,我不会写太多关于知识点的东西,因为这些知识点大家可以自行Google可以RTFM。我要写就一定是以体系化的,而且要能直达技术的本质。我入行这20年来,我最擅长的是针对各种大规模的系统,所以,我会有2-3个和分布式系统相关的系列文章,然后,我学过也用过好多编程语言,所以,我也会有一系列的关于编程本质的文章,而我对一些基础知识研究的也比较多,所以,还会有一系列的和基础知识相关的文章。当然,其中还会穿插一些其它的技术文章,比如一些热点事件,还有一些经验之谈,包括,我会把我的《程序员技术练级攻略》在这个专栏里重新再写一遍。这些东西一定会让大家有醍醐灌顶的感觉。
  • 成长。在过去这20年中,我感觉得到,很多人都会非常在意自己的成长。所以,我会分享一堆我亲身经历的,也是我自己实验的一定和个人发展相关的文章。比如,像技术变现啊、如何面试、如何选择新的技术、如何学习、如何管理自己的时间、如何管理自己的老板和工作、如何成为一个Leader……这些东西一定会对大家有用。但是,我这里一定不会有速成的东西。一切都是要花时间和精力的。如果你想要速成,你不应该来订阅我的专栏。
  • 管理。这20年,我觉得做好技术工作,得做好技术的管理工作,只有管理好了软件工程和技术团队,技术才能发挥出最大的潜力。大多数的技术都是管理上的问题。所以,我会写上一系列的和管理相关的文章,管理三个要素,团队、项目和管理者自己。所以,我会从这三个方面写一系列包括,人员招聘、绩效考核、提升士气、解决冲突、面对变化、沟通说服、项目管理、任何排期、会议、远程管理……等等一系列的文章。这些东西都是我在外企时,接受到的世界顶级管理培训机构培训内容,我会把我的实践写出来分享给大家。这其中一定少不了亚马逊相关的各种实践。这些东西,我和很多公司和大佬都讲过,到目前为止还没有人不赞的。

现在,我这个专栏写了快三个月了,第一部分和第二部分已经有一些呈现了。我周末和假期的时间也完全都搭进去了 ;-)。后面的文章还在和我的编辑一起在整理和书写中,我感觉这个专栏只收199一年简直是太便宜了,我有点想涨价的冲动了。哈哈。

幕后团队

最后说一下我的专栏编辑——她叫杨爽!以前是CSDN的程序员杂志的编辑,后来去了七牛,现在和我一起做我的这个专栏。她对我的这个专栏上的投入非常大,除了帮助我编辑文章,还要帮音频师标注语气,英文发音,以及音频版的文章,还要深度参与写作,有的文章我只给了一个大纲,甚至只是一个方向,或是一系列的素材,然后都是她来操刀的,比如“推荐阅读”的文章、还有技术领导力的下篇,基本上是由杨爽来出第一版,然后我再上面再做修改和补充。她说,写技术文章真是太累了,尤其是帮你编辑你的分布式系列的文章,我基本都把这些技术都看了个大概了。我调侃到,如果你完全搞懂了,你就不用做编辑了,你可以做技术去了,嗯,而且,可以变成架构师了。

另外,她会深度的编辑我的文章,尤其是每篇文章最后的一些总结或是一些问题都是她写的。在我的一篇答疑的文章中,她自己加入了一个观点——“很多事情能做到什么程度,其实在思想的源头就被决定了,因为它会绝大程度地受到思考问题出发点、思维方式、格局观、价值观等因素的影响”,这个观点被读者当成是我的观点,其实,这是杨爽的观点,当然我也很同意。

所以,我的这个专栏离不开杨爽的付出,我和她一般都是在晚上或是周末沟通,因为平时我的时候都被创业的事给占据了。所以,她也只能适配我的时间,但她真的很努力,我能感觉得到她想把文章的质量不断提高的迫切。

关于专栏的音频师,他叫柴巍,是天津广播电台的主持人,一个89年的小伙子,网上他的个人信息在这里。他跨界来读这些技术文章的确对他来说非常不容易,因为一方面这文章里讲的这些东西他都看不懂,另外,他也不认识我,我脾气和性格他不知道,所以,他读我的文章里,并不能完全准确地把握相关的语气。这就需要杨爽来帮他标注和调整,有些地方,不断地修改,不断地录,大家知道,录音和写文章不一样,文章要修改很简单,语音要修改就非常麻烦,得把上下文全都一并重新再读一篇,这个过程的确难,杨爽在其中也花费了大量的时间和这个小伙子沟通和调整。

在一开始,有播音腔,也被读者吐槽了,他自己后来一直在调整,目前越来越符合咱们的要求。这个小哥是非常努力和有挑战精神的,他在这个过程中,也是非常信守承诺的。去年12月6日,录分布式系统冰与火那篇文章时,他上午有自己的工作,下午要开会,晚上又有单位活动,他还是活动的主持人,他实在是没有时间了。我也和我的编辑说,算了,先发文章,后面再补音频。但是他还是挤时间把音频录出来了,期间,我还不知情地又修改了一下文章,他又配合修改,直到完全改好。打车去参加活动,还好提前20分钟赶到,没有耽误主持活动。

唠唠叨叨写这么多,也没什么干货!算是一份记录吧。也希望大家能够从我的专栏中看到这个团队的确是在用心做事的,是的,能认识这些人,还能一起合作,在我的人生经历上是非常有价值的事了。

希望大家在新的一年里也能遇到这样的人。我们一起加油!

图片来自:电影《速度与激情》——Ride or Die

 

(全文完)

 


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/18246.html/feed 45
Go语言、Docker 和新技术 http://www.chinamxjy.com/articles/18190.html http://www.chinamxjy.com/articles/18190.html#comments Mon, 30 Oct 2017 01:24:20 +0000 http://www.chinamxjy.com/?p=18190 Read More Read More

]]>
上个月,作为 Go 语言的三位创始人之一,Unix 老牌黑客罗勃·派克(Rob Pike)在新文章“Go: Ten years and climbing”中,回顾了一下 Go 语言的发展过程。其中提到,Go 语言这十年的迅猛发展大到连他们自己都没有想到,并且还成为了云计算领域中新一代的开发语言?;固岬搅?,中国程序员对 Go 语言的热爱完全超出了他们的想象,甚至他们都不敢相信是真的。

这让我想起,我在 2015 年 5 月份拜访 Docker 公司在湾区的总部时,Docker 负责人也和我表达了相似的感叹:他们完全没有想到居然中国有那么多人喜欢 Docker,而且还有这么多人在为 Docker 做贡献,这让他们感到非常意外。此外,还跟我说,中国是除了美国本土之外的另一个如此喜欢 Docker 技术的国家,在其它国家都没有看到。

的确如他们所说,Go 语言和 Docker 这两种技术已经成为新一代的云计算技术,而且可以看到其发展态势非常迅猛。而中国也成为了像美国一样在强力推动这两种技术的国家。这的确是一件让人感到非常高兴的事,因为中国在跟随时代潮流这件事上已经做得非常不错了。

然而,从 2014-2015 年我在阿里推动 Docker 和 Go 语言的痛苦和失败过程中,以及这许多年来,有很多很多人问我是否要学 Go 语言,是否要学 Docker,Go 和 Docker 是否能用在生产线上,这些问题看来,对于 Go 语言和 Docker 这两种技术,在国内的技术圈中有相当大的一部分人和群体还在执观望或是不信任的态度。

所以,我想写这篇文章,从两个方面来论述一下我的观点和看法。

  • 一个方面,为什么 Go 语言和 Docker 会是新一代的云计算技术。
  • 另一个方面,作为技术人员,我们如何识别什么样的新技术会是未来的趋势。

这两个问题是相辅相成的,所以我会把这两个问题揉在一起谈。

虽然 Go 语言是在 2009 年底开源的,但我是从 2012 年才开始接触和学习 Go 语言的。我只花了一个周末两天的时间就学完了,而且在这两天,我还很快地写出了一个能工作很好的网页爬虫程序,以及一个简单的高并发文件处理服务,用于提取前面抓取的网页的关键内容。这两个程序都很简单,总共才写了不到 500 行代码。

我当时对 Go 语言有几点体会。

第一,语言简单,上手快。Go 语言的语法特性简直是太简单了,简单到你几乎玩不出什么花招,直来直去的,学习曲线很低,上手非???。

第二,并行和异步编程几乎无痛点。Go 语言的 Goroutine 和 Channel 这两个神器简直就是并发和异步编程的巨大福音。像 C、C++、Java、Python 和 JavaScript 这些语言的并发和异步方式太控制就比较复杂了,而且容易出错,而 Go 解决这个问题非常地优雅和流畅。这对于编程多年受尽并发和异步折磨的我来说,完全就是让我眼前一亮的感觉。

(图片来自 Medium:Why should you learn Go?

第三,Go 语言的 lib 库麻雀虽小五脏俱全。Go 语言的 lib 库中基本上有绝大多数常用的库,虽然有些库还不是很好,但我觉得不是问题,因为我相信在未来的发展中会把这些问题解决掉。

第四,C 语言的理念和 Python 的姿态。C 语言的理念是信任程序员,保持语言的小巧,不屏蔽底层且底层友好,关注语言的执行效率和性能。而 Python 的姿态是用尽量少的代码完成尽量多的事。于是我能够感觉到,Go 语言想要把 C 和 Python 统一起来,这是多棒的一件事啊。

(图片来自 Medium:Why should you learn Go?

所以,即便 Go 语言存在诸多的问题,比如垃圾回收、异常处理、泛型编程等,但相较于上面这几个优势,我认为这些问题都是些小问题。于是就毫不犹豫地入坑了。

当然,一个技术能不能发展起来,关键还要看三点。

  • 有没有一个比较好的社区。像 C、C++、Java、Python 和 JavaScript 的生态圈都是非常丰富和火爆的。尤其是有很多商业机构参与的社区那就更为人气爆棚了,比如 Linux 的社区。
  • 有没有一个工业化的标准。像 C、C++、Java 都是有标准化组织的。尤其是 Java,其在架构上还搞出了像 J2EE 这样的企业级标准。
  • 有没有一个或多个杀手级应用。C、C++ 和 Java 的杀手级应用不用多说了,就算是对于 PHP 这样还不能算是一个好的编程语言来说,因为是 Linux 时代的第一个杀手级解决方案 LAMP 中的关键技术,所以,也发展起来了。

上述的这三点是非常关键的,新的技术只需要占到其中一到两点就已经很不错了,何况有的技术,比如 Java,是三点全占到了,所以,Java 的发展是如此好。当然,除了上面这三点重要的,还有一些其它的影响因素,比如:

  • 学习曲线是否低,上手是否快。这点非常重要,C++ 在这点上越做越不好了。
  • 有没有一个不错的提高开发效率的开发框架。如:Java 的 Spring 框架,C++ 的 STL 等。
  • 是否有一个或多个巨型的技术公司作为后盾。如:Java 和 Linux 后面的 IBM、Sun……
  • 有没有解决软件开发中的痛点。如:Java 解决了 C 和 C++ 的内存管理问题。

用这些标尺来量一下 Go 语言,我们可以清楚地看到:

  • Go 语言容易上手;
  • Go 语言解决了并发编程和写底层应用开发效率的痛点;
  • Go 语言有 Google 这个世界一流的技术公司在后面;
  • Go 语言的杀手级应用是 Docker,而 Docker 的生态圈在这几年完全爆棚了。

所以,Go 语言的未来是不可限量的。当然,我个人觉得,Go 可能会吞食很多 C、C++、Java 的项目。不过,Go 语言所吞食主要的项目应该是中间层的项目,既不是非常底层也不会是业务层。

也就是说,Go 语言不会吞食底层到 C 和 C++ 那个级别的,也不会吞食到高层如 Java 业务层的项目。Go 语言能吞食的一定是 PaaS 上的项目,比如一些消息缓存中间件、服务发现、服务代理、控制系统、Agent、日志收集等等,没有复杂的业务场景,也到不了特别底层(如操作系统)的中间平台层的软件项目或工具。而 C 和 C++ 会被打到更底层,Java 会被打到更上层的业务层。这是我的一个判断。

好了,我们再用上面的标尺来量一下 Go 语言的杀手级应用 Docker,你会发现基本是一样的。

  • Docker 上手很容易。
  • Docker 解决了运维中的环境问题以及服务调度的痛点。
  • Docker 的生态圈中有大公司在后面助力。比如 Google。
  • Docker 产出了工业界标准 OCI。
  • Docker 的社区和生态圈已经出现像 Java 和 Linux 那样的态势。
  • ……

所以,早在 3、4 年前我就觉得 Docker 一定会是未来的技术。虽然当时的坑儿还很多,但是,相对于这些大的因素来说,那些小坑儿都不是问题。只是需要一些时间,这些小坑儿在未来 5-10 年就可以完全被填平了。

同样,我们可以看到 Kubernetes 作为服务和容器调度的关键技术一定会是最后的赢家。这点我在去年初就能够很明显地感觉到了。

关于 Docker 我还想多说几句,这是云计算中 PaaS 的关键技术,虽然,这世上在出现 Docker 之前,几乎所有的要玩公有 PaaS 的公司和产品都玩不起来,比如:Google 的 GAE,国内的各种 XAE,如淘宝的 TAE,新浪的 SAE 等。但我还是想说,PaaS 是一个被世界或是被产业界严重低估的平台。

PaaS 层是承上启下的关键技术,任何一个不重视 PaaS 的公司,其技术架构都不可能让这家公司成长为一个大型的公司。因为 PaaS 层的技术主要能解决下面这些问题。

  • 软件生产线的问题。持续集成和持续发布,以及 DevOps 中的技术必需通过 PaaS。
  • 分布式服务化的问题。分布式服务化的服务高可用、服务编排、服务调度、服务发现、服务路由,以及分布式服务化的支撑技术完全是 PaaS 的菜。
  • 提高服务的可用性 SLA。提高服务可用性 SLA 所需要的分布式、高可用的技术架构和运维工具,也是 PaaS 层提供的。
  • 软件能力的复用。软件工程中的核心就是软件能力的复用,这一点也完美地体现在 PaaS 平台的技术上。

老实说,这些问题的关键程度已经到了能判断一家依托技术的公司的研发能力是否靠谱的程度。没有这些技术,依托技术拓展业务的公司几乎没有可能发展得规模很大。

在后面,我会在“极客时间我的付费专栏里另外写几篇文章详细地讲一下分布式服务化和 PaaS 平台的重要程度。

最后,我还要说一下,为什么要早一点地进入这些新技术,而不是等待这些技术成熟了后再进入。原因有这么几个。

技术的发展过程非常重要。我进入 Go 和 Docker 的技术不能算早,但也不算晚,从 2012 年学习 Go,到 2013 年学习 Docker 到今天,我清楚地看到了这两种技术的生态圈发展过程。让我收获最大的并不是这些技术本身,而是一个技术的变迁和行业的发展。

从中,我看到了非常具体的各种思潮和思路,这些东西比起 Go 和 Docker 来说更有价值。因为,这不但让我重新思考我已掌握的技术以及如何更好地解决已有的问题,而且还让我看到了未来。我不但有了技术优势,而且这些知识还让我的技术生涯多了很多的可能性。

这些关键新技术,可以让你拿到技术的先机。这些对一个需要技术领导力的个人或公司来说都是非常重要的。

一个公司或是个人能够占有技术先机,就会比其它公司或个人有更大的影响力。一旦未来行业需求引爆,那么这个公司或是个人的影响力就会形成一个比较大的护城河,并可以快速地产生经济利益。

近期,在与中国移动、中国电信以及一些股份制银行进行交流的过程中,我已看到通讯行业、金融行业对于 PaaS 平台的理解已经超过了互联网公司,而我近 3 年来在这些技术上的研究让我也从中受益非浅。

所以,Go 语和 Docker 作为 PaaS 平台的关键技术前途是无限的,我很庆幸赶上了这个浪潮,也很庆幸在 3 年前我就看到了这个趋势,现在我也在用这些技术开发相关的技术产品,助力于为高速成长的公司提供这些关键技术。

 

最后注明一下:

这篇文章于上周发布于“极客时间”的我的付费专栏中。极客时间中的付费是我受Geekbang邀请写的一个付费专栏,因为过去10多年给企业有过很多内训,过去2年又给好多企业做过一些咨询工作,所以,我会把一些商业化的内容写在极客时间里,当然,也会有一些我的新文章。关于这个事,我后面我专门开一篇文章说一下。(大家可以到 Apple的App Store上搜极客时间,Android版本等到12月初吧)

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/18190.html/feed 36
关于Facebook 的 React 专利许可证 http://www.chinamxjy.com/articles/18140.html http://www.chinamxjy.com/articles/18140.html#comments Tue, 19 Sep 2017 06:08:00 +0000 http://www.chinamxjy.com/?p=18140 Read More Read More

]]>
随着Apache、百度、Wordpress都在和Facebook的React.js以及其专利许可证划清界限,似乎大家又在讨论Facebook的这个BSD+PATENT的许可证问题了。这让我想起了之前在Medium读过的一篇文章——《React, Facebook, and the Revocable Patent License, Why It’s a Paper》,我觉得那篇文章写的不错,而且还是一个会编程的律师写的,所以有必要把这篇文章传播到中文社区这边来。注意,我不会全部翻译,我只是用我的语言来负责搬运内容和观点,我只想通过这篇文章让大家了解一下这个世界以及专利相关的知识,这样可以避免你看到某乎的“怎么看待XXX”这类的问题时人云亦云,能有自己的独立思考和自我判断。;-)

这篇文章的作者叫Dennis Walsh,他自称是亚历桑那和加利福尼亚州的律师,主要针对版权法和专利诉论的法律领域。但是这个律师不一样,他更很喜欢商业和软件多一些。现在他用React/GraphQL/Elixir在写一个汽车代理销售相关的软件,而且已经发布到第2版了。

首先,作者表明,专利法经常被人误解,因为其实充满了各种晦涩难懂的法律术语,所以,作者用个例子来讲述专利的一个原则 —— 专利并不是授于让你制造或开发的权利,而是授予你可以排他的权利。(事实上似乎也是这样,申请专利很多时候都不是为了制作相关的产品,而是为了防止别人使用类似的技术制作相关的产品)

如果有公司X为铅笔申请了专利,而另一家公司Y为把用于铅笔的橡皮擦申请了专利。那么,公司X可以阻止公司Y来生产铅笔,而对带橡皮擦的铅笔没办法,但是公司Y的专利可以让公司X不能生产带有橡皮擦的铅笔。

所以,公司Y的橡皮擦专利又被广泛地叫作“Blocking Patent”。公司Y不能说他发明了铅笔,因为这是公司X的专利,但是,他们可以让公司X无法对铅笔做出某些改进。

于是,因为这种 Blocking Patent 存在,对于开源的公司是不利的,因为根据上面的那个例子来说,开源公司就是公司X,他们做了一个基础的软件,而公司Y在上面做了些改进,并注册成了专利,从而导致开源的公司X无法对它基础开源软件作出被公司Y专利阻止的改进,开源的公司X希望能够自由地使用公司Y的橡皮擦专利,因为毕竟是它发明了铅笔并放弃了铅笔的专利。

于是就出来了“专利反击条款”(Patent Retaliation Clauses)。一般来说有两种专利条款,一种是弱条款,一种是强条款。

Weak Patent Retaliation Clauses – 这种条款声明,如果许可证持有者用某个专利来打击许可证颁布者,那么专利就视为终止。用人话来表达就是,公司X做了一个开源铅笔,而公司Y注册了橡皮檫专利。此时,公司X做了一支带像皮擦的铅笔,而公司Y马上对公司X提起专利侵权诉讼。那么,公司Y就失去了对底层铅笔的专利控制。(正如前面所说的,公司Y的橡皮擦专利因为在起诉公司X的开源铅笔,而失去了对开源铅笔的专利排他权利)

Strong Patent Retailiation Clauses – 这种条款声明比“弱条款”要的更多。具体来说就是,任何专利声明终结许可证,而不管这个专利有没有和你基础的软件有关系。用人话来说就是,公司Y使用他们的热气球专利来起诉公司X,那么公司Y就失去了他们对铅笔的专利限制。

我个人理解起来,这两种条款看上去是防御性质的。

Facebook的React的Patent License如下:

The license granted hereunder will terminate, automatically and without notice,if you (or any of your subsidiaries, corporate affiliates or agents) initiatedirectly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporateaffiliates, (ii) against any party if such Patent Assertion arises in whole orin part from any software, technology, product or service of Facebook or any ofits subsidiaries or corporate affiliates, or (iii) against any party relating to the Software. Notwithstanding the foregoing, if Facebook or any of itssubsidiaries or corporate affiliates files a lawsuit alleging patentinfringement against you in the first instance, and you respond by filing apatent infringement counterclaim in that lawsuit against that party that isunrelated to the Software, the license granted hereunder will not terminateunder section (i) of this paragraph due to such counterclaim.

这些条款中和基础软件没有任何关系,所以,这个条款是“强专利反击条款”。

在后面,本文的作者又解解释了,为什么React的“强专利反击条款”就跟没有似的。他在文中针对一些歇斯底里的言论,如:“Facebook不用害怕专利诉讼了,而且他可以随时偷袭你家的专利仓库”,也作出了一些解释来分析这个事。

Contractural Liability – 意思是说,专利方面的东西只会影响专利上的事,而不会影响和专利无关的事,React底层协议是BSD-3许可证还是会被保留?;痪浠八?,React的“强专利反击条款”只生效于专利层面,而不会对非常专利的软件使用产生问题,如果和专利无关,React还是走BSD-3的许可协议。

Copyright Liability – 这个和Contractural Liablitity 一样。作者说,如果有人有特别的案例或是有说服力的论据来说明Facebook的这个条款会作用于非专利的地方,那么,请告诉他。

Patent Liability – 专利的责任和损害是两件事,非专业人士总是会把其搞混。

第一个问题是Liability, 要搞清这个事,得搞清“Patent’s Claims”,而不是这个技术的技术规格说明,技术规格说明和权力主张是两码事。作者说,现在的很多专利都是一些想法,很多投机份子随便一拍脑袋就发明出一个想法,然后就去注册专利了。但是可以被用来法律执行的只有“Patent’s Claims”(专利的权利主张),而不是那些想法。这些权利主张相当相当的晦涩难读,而且是会故意被模糊掉的,因为,当你清楚的定义了你的发明是什么,那么,就可以清楚的定义出来什么不是你的发明。比如:一个铅笔专利权利主张里说,“这一个用石墨和木头组合起来的写字工具”,那么,只要我不用木头和石墨来做组合,而是用塑料来做组合,那么我就不是专利侵权。所以,一般来说,专利主张是会更为通用一些,比如,“这是一个用于涂画表面的装置,其包括:与涂画端相连的握持端”。作者这里给了一个苹果公司的滑动解锁专利的示例??梢愿惺芤幌虏饭娓袼得骱妥ɡɡ髡磐耆橇铰胧?。

专利这些事,在法律界里是非常非常困难作出评估的。所以,这个社会每年都会给律师们几十亿美金来一遍又一遍地回答这些问题,而且律师还经?;卮鸫砹?。而对于美国的法律,对于专利诉讼会有一个叫Markman hearing的审前听证会(马克曼听证会),自从1996年美国最高法的“马克曼诉威斯幽仪器公司案”这个听证会就变成了一个惯例,美国联邦法院用这个听证会来向决定专利权利主张的解释,而且,上诉法院还经常性的推翻审判法院的裁决。(对于美国法律来说,一般是法官认证法律,陪审团认定事实,然而,对于专利而言,1996年的那个案件认为专利术语是一个需要法官决定的法律问题,而不是陪审团决定的事实问题。关于马克曼听证会的事,可以参看本文未尾的附录)

所以,要决定Facebook的专利责任,我们需要评估Facebook的专利及其权利主张,而不是技术规格说明。具体来说,要明确Facebook对于React这个底层技术的专利权利主张是什么?但是作者搜了一下,发现什么也没有找到。也就是说,对于USPTO(美国专利商标局)或法院来说,他们没办法对Facebook的这样没有为React申请专利的方式来执行任何和专利的诉讼,也就是说,Facebook的这个React License的条款,美国政府是无法在法律上支持的。

第二个问题是专利损害。就算是Facebook可以评估出来一个合法可执行的专利来?;eact,对于专利损害也是很有问题的。作者说他到目前还没有发现一个开源软件被专利侵权的事,就算有这样的案例,也不会是这里说的这个事。作者觉得在这个事上操作起来就是一个笑话。

另外,作者认为,React 专利许可证这个事就是个纸老虎。因为,一方面,这个专利不像电信通讯里的那些专利,你拿不掉。作者认为要从你的代码中把React去掉虽然难,但是也不是什么很难的事,另外,要打这样的专利官司,一般来说,在美国至少要花100-200万美金的费用才能发起诉讼,而要胜诉则需要需要200多万到2000万美金的费用,你觉得你要花多钱才能把React从你的代码库中剔除?肯定比这钱少。

作者还认为,Facebook玩这个事虽然出发点不错,但是感觉并不聪明,从目前的情况看下来,就像他想咬你一口,但却没有牙。

后面,作者还说了一下,转成别的框架会不会有问题?比如:你用Preact/Vue或是你自研的东西?作者说,未必,如果Facebook真的为React注册了专利,比如:React里的组件技术、虚拟DOM渲染技术等等。那么,你用Preact/Vue或是带这样技术的自研的框架,那么,从你使用的第一天就在侵犯Facebook的专利权了。然而,使用React反而不会有这么大的风险,因为Facebook让你免费的用React。作者说,用别的框架的法律风险比用其它替代品的风险更高。

后面,作者也更新了一篇文章 《Using GraphQL? Why Facebook Now Owns You》,意思是,用React可能还好,但是用GraphQL就有问题了。因为找到了GraphQL的专利—— “Graph Query Logic”。

后来我查了一下,我发现,React也有个相关的专利—— “Efficient event delegation in browser scripts ”,看上去和虚拟DOM渲染有关。Holy Shit!

好了,用还是不用React我也不知道,总之,这个世界比较复杂,我只是想借这篇文章来学习一下法律上的相关东西,欢迎听到大家的观点。

最后,请允许我调侃一下来结束本文——“不用担心React的许可证问题,因为前端不是一年半就用新的框架重写一次么?”哈哈。

更新:Facebook官方于20017年9月23日在其官方blog上发贴《Relicensing React, Jest, Flow, and Immutable.js》决定取消之前的带专利的许可证。

延伸阅读

马克曼听证会 – Markman Hearing

马克曼听证会的一些背景知识,下面的文字来源于《“马克曼听证”制度的由来及启示

与美国专利诉讼的悠长历史相比,1996年才经美国最高法院确立的“马克曼听证”(Markman Hearing,也称为Claim Construction,即权利要求书的解释)无疑是一项年轻的制度。但由于几乎所有的专利侵权诉讼中都会遇到涉案专利权利要求书的解释这一核心问题,且因“马克曼听证”结果往往清楚地预示了案件结果,经“马克曼听证”获得有利结论的一方一旦据此向法庭提起不审即判的动议,专利侵权诉讼往往可就此快速了结,因此该制度的确立成为美国专利诉讼历史上的一件大事。

“马克曼听证”制度的由来

“马克曼听证”制度确立之前,在专利侵权诉讼中的权利要求书解释,通常交由陪审团在对案件事实进行裁决时一并做出,且并不会在诉讼文件上单独就陪审团这一问题的判断进行记录。1991年,马克曼(Markman)先生因认为其拥有的专利号为RE33054的“干洗衣物贮存及追踪控制装置”专利权被Westview公司所侵犯,遂向宾夕法尼亚州东区联邦地方法院提起了专利侵权诉讼。

该专利是用扫描的方式,将客户的衣物编号扫描后输入电脑中做分类标示,并在衣物干洗过程中追踪衣物位置,干洗完成后自动将衣物放回客户固定的存贮位置。被告的产品则是同时运用扫描器和电脑两种方式,将客户干洗衣物的资料存入电脑并显示费用、日期等相关信息。本案陪审团的裁决认为被告装置构成对原告专利权利的侵犯,但该地方法院认为系争专利与被告装置在功能实施上并不一致,遂推翻陪审团的裁决,判决被告不构成侵权。

马克曼不服,于1995年向联邦上诉法院提起上诉,但其上诉理由仅为联邦地方法院错误地解释了陪审团关于专利权利要求书解释中某个词语的涵义。联邦上诉法院在审理该案时,将案件的核心问题定为两个:一是原告对于请求项解释有无权利请求陪审团裁决;二是联邦地方法院是否正确地解释了“Inventory”一词。该院多数法官经审理后认为,权利要求书范围的解释与确定,属于法律问题而非事实问题,因而属于法院权限,而不应交由陪审团决定,且此前将此问题交由陪审团确定并不妥当。同时,由于认为原告专利与被告装置存在实质功能上的差异,联邦上诉法院亦不认为被告构成专利侵权。少数持不同意见的该院法官主要是质疑这一结论违反了美国第七宪法修正案(即所有根据美国法律进行的普通法诉讼,只要争议金额超过20美元,即有要求陪审团审判的权利)。

马克曼不服,向最高法院提出上诉。1996年4月23日,美国最高法院就马克曼诉Westview器械公司案(Markman v. Westview Instruments, Inc. 517 U.S. 370 (1996))做出终审裁决,裁决认定:权利要求书的解释是联邦地区法院法官应当处理的法律问题,而不是应当由陪审团来认定的事实问题,尽管在解释权利要求书的过程中可能会包含一些对于事实问题的解释,且这样做并不违反第七修正案赋予给陪审团的权利。这一裁决标志着“马克曼听证”制度的正式确立。

“马克曼听证”制度的不足

该案判决是美国专利诉讼史上的一个重大转折?!奥砜寺ぁ背晌ü僮庞糜诮馐妥ɡɡ蟮囊桓鼍P蕴こ绦?,用以解决专利侵权诉讼的核心问题。由于该听证并非普遍适用,因此,十几年来,联邦民事诉讼规则并未正式对其有任何规定,而是给予法院绝对的自由裁量权。但是,何时可以进行“马克曼听证”?如何进行?是否有必要进行?类似问题在一定程度上困扰了审理专利侵权案件较多的法院。

2001年,加州北区联邦地区法院率先制定了供本法院使用的专利审判专属规则(Patent Local Rules),其中第四部分即为权利要求书的解释程序(Claim Construction Proceddings),对“马克曼听证”的时间、流程、限制及当事人的义务均进行了规定。此后,各州纷纷效仿。目前,乔治亚州北区联邦法院、得克萨斯州东区联邦法院、得克萨斯州南区联邦法院、宾夕法尼亚州西区联邦法院等都制订了书面的“马克曼听证”程序指南。近年来,不断有新的案例在解释与细化着“马克曼听证”,如2006年的Wilson Sporting Goods Co.诉Hillerich & Bradsby Co.案,2005年的Phillips诉AWH Corp.案,2008年的Howmedica Osteonics Corp.诉Wright Medical Technology, Inc.案,这些司法实践大大拓展与丰富了“马克曼听证”使用的实体和程序规则,使之日渐成为美国专利诉讼中一个复杂、完备的司法程序。以至于竟然有人开发了模拟“马克曼听证”程序,只要你愿意,可以下载并训练,以熟悉和确保有真正的权利要求书解释时不会出现不利于自己的问题。

但是,该听证带来的问题也逐渐受到重视。有人质疑说该程序导致专利诉讼费用增加,因为“马克曼听证”通?;岬ザ澜?,且程序复杂,因此导致当事人花费大量的时间与精力,更为重要的是,由于40%至60%的联邦地区法院案件会在联邦巡回上诉法院被推翻,因此,花费巨大的“马克曼听证”似乎价值有限。同时,权利要求书的解释要求是不多不少,忠实于技术发明思想与发明事实,但由于地区法院分散,法官的相关技术知识不十分专业,将权利要求书解释这样的问题交给他们,难免会带来一些无法克服的问题。

“马克曼听证”制度的启示

我国民事诉讼中并无陪审团制度,案件的事实问题与法律问题均由法官审理与确定。在专利侵权诉讼中,对于案件中涉及到的技术问题可以通过专家鉴定等方式解决,但并不因此免除法官审理案件的义务,即法律问题的判断归于法官,事实的法律属性判断仍然归于法官。同时,权利要求书的解释在我国的专利侵权诉讼中并不是一个单独的程序,而是合并在案件审理过程中。因此,仅就我国的司法审判而言,“马克曼听证”制度并无直接的借鉴意义。

但是,对于那些已经走出和正在走出国门的企业来说,了解与掌握这一重要的专利诉讼程序却是极其重要的。通领科技集团的积极尝试充分证明了这一点,而且随着这一程序的不断成熟,美国国际贸易法院(ITC)也开始在审理时适用“马克曼听证”制度。所以,知道“马克曼听证”意味着什么,确保所提交的用于解释权利要求的文件确实充分,学会利用“马克曼听证”,无论是对于破解美国的专利诉讼威胁,还是为未来准备有效的法律武器,无疑都非常重要。(知识产权报 作者 魏玮)

 

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/18140.html/feed 23
如何免费的让网站启用HTTPS http://www.chinamxjy.com/articles/18094.html http://www.chinamxjy.com/articles/18094.html#comments Sat, 26 Aug 2017 06:06:17 +0000 http://www.chinamxjy.com/?p=18094 Read More Read More

]]>
今天,我把CoolShell变成https的安全访问了。我承认这件事有点晚了,因为之前的HTTP的问题也有网友告诉我,被国内的电信运营商在访问我的网站时加入了一些弹窗广告。另外,HTTP的网站在搜索引擎中的rank会更低。所以,这事早就应该干了。现在用HTTP访问CoolShell会被得到一个 301 的HTTPS的跳转。下面我分享一下启用HTTPS的过程。

我用的是 Let’s Encrypt这个免费的解决方案。Let’s Encrypt 是一个于2015年推出的数字证书认证机构,将通过旨在消除当前手动创建和安装证书的复杂过程的自动化流程,为安全网站提供免费的SSL/TLS证书。这是由互联网安全研究小组(ISRG – Internet Security Research Group,一个公益组织)提供的服务。主要赞助商包括电子前哨基金会,Mozilla基金会,Akamai以及Cisco等公司(赞助商列表)。

2015年6月,Let’s Encrypt得到了一个存储在硬件安全??橹械睦胂叩腞SA根证书。这个由IdenTrust证书签发机构交叉签名的根证书被用于签署两个证书。其中一个就是用于签发请求的证书,另一个则是保存在本地的证书,这个证书用于在上一个证书出问题时作备份证书之用。因为IdenTrust的CA根证书目前已被预置于主流浏览器中,所以Let’s Encrypt签发的证书可以从项目开始就被识别并接受,甚至当用户的浏览器中没有信任ISRG的根证书时也可以。

以上介绍文字来自 Wikipedia 的 Let’s Encrypt 词条。

为你的网站来安装一个证书十分简单,只需要使用电子子前哨基金会EFF的 Certbot,就可以完成。

1)首先,打开?https://certbot.eff.org 网页。

2)在那个机器上图标下面,你需要选择一下你用的 Web 接入软件 和你的 操作系统。比如,我选的,nginx?和 Ubuntu 14.04

3)然后就会跳转到一个安装教程网页。你就照着做一遍就好了。

以betway手机客户端 www.chinamxjy.com为例 – Nginx + Ubuntu

首先先安装相应的环境:

$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install python-certbot-nginx

然后,运行如下命令:

$ sudo certbot --nginx

certbot 会自动检查到你的 nginx.conf 下的配置,把你所有的虚拟站点都列出来,然后让你选择需要开启 https 的站点。你就简单的输入列表编号(用空格分开),然后,certbot 就帮你下载证书并更新 nginx.conf 了。

你打开你的 nginx.conf?文件 ,你可以发现你的文件中的 server?配置中可能被做了如下的修改:

listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/coolshell.cn/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/coolshell.cn/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot

 # Redirect non-https traffic to https
if ($scheme != "https") {
  return 301 https://$host$request_uri;
} # managed by Certbot

 

这里建议配置 http2,这要求 Nginx 版本要大于 1.9.5。HTTP2 具有更快的 HTTPS 传输性能,非常值得开启(关于性能你可以看一下这篇文章)。需要开启HTTP/2其实很简单,只需要在 nginx.conf?的 listen 443 ssl;?后面加上 http2?就好了。如下所示:

listen 443 ssl http2; # managed by Certbot 
ssl_certificate /etc/letsencrypt/live/coolshell.cn/fullchain.pem; # managed by Certbot 
ssl_certificate_key /etc/letsencrypt/live/coolshell.cn/privkey.pem; # managed by Certbot 
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot

然后,就 nginx -s reload?就好了。

但是,Let’s Encrypt 的证书90天就过期了,所以,你还要设置上自动化的更新脚本,最容易的莫过于使用 crontab?了。使用 crontab -e?命令加入如下的定时作业(每个月都强制更新一下):

0 0 1 * * /usr/bin/certbot renew --force-renewal
5 0 1 * * /usr/sbin/service nginx restart

当然,你也可以每天凌晨1点检查一下:

0 1 * * * certbot renew 

注:crontab 中有六个字段,其含义如下:

  • 第1个字段:分钟 (0-59)
  • 第2个字段:小时 (0-23)
  • 第3个字段:日期 (1-31)
  • 第4个字段:月份 (1-12 [12 代表 December])
  • 第5个字段:一周当中的某天 (0-7 [7 或 0 代表星期天])
  • /path/to/command – 计划执行的脚本或命令的名称

这么方便的同时,我不禁要问,如果是一些恶意的钓鱼网站也让自己的站点变成https的,这个对于一般用来说就有点难以防范了。哎……

当然,在nginx或apache上启用HTTPS后,还没有结束。因为你可能还需要修改一下你的网站,不然你的网站在浏览时会出现各种问题。

启用HTTPS后,你的网页中的所有的使用 http://?的方式的地方都要改成 https://?不然你的图片,js, css等非https的连接都会导致浏览器抱怨不安全而被block掉。所以,你还需要修改你的网页中那些 hard code http://?的地方。

对于我这个使用wordpress的博客系统来说,有这么几个部分需要做修改。

1)首先是 wordpress的 常规设置中的 “WordPress 地址” 和 “站点地址” 需要变更为 https 的方式。

2)然后是文章内的图片等资源的链接需要变更为 https 的方式。对此,你可以使用一个叫 “Search Regex” 插件来批量更新你历史文章里的图片或别的资源的链接。比如:把 http://www.chinamxjy.com?替换成了 http://www.chinamxjy.com

3)如果你像我一样启用了文章缓存(我用的是WP-SuperCache插件),你还要去设置一下 “CDN” 页面中的 “Site URL” 和 “off-site URL” 确保生成出来的静态网页内是用https做资源链接的。

基本上就是这些事。希望大家都来把自己的网站更新成 https 的。

嗯,12306,你什么时候按照这个教程做一下你的证书?

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/18094.html/feed 72
API设计原则 – Qt官网的设计实践总结 http://www.chinamxjy.com/articles/18024.html http://www.chinamxjy.com/articles/18024.html#comments Tue, 25 Jul 2017 06:16:30 +0000 http://www.chinamxjy.com/?p=18024 Read More Read More

]]>
(感谢好友 @李鼎 翻译此文)

原文链接:API Design Principles?–?Qt Wiki
基于Gary的影响力上?Gary Gao?的译文稿:C++的API设计指导

译序

api design

Qt的设计水准在业界很有口碑,一致、易于掌握和强大的API是Qt最著名的优点之一。此文既是Qt官网上的API设计指导准则,也是Qt在API设计上的实践总结。虽然Qt用的是C++,但其中设计原则和思考是具有普适性的(如果你对C++还不精通,可以忽略与C++强相关或是过于细节的部分,仍然可以学习或梳理关于API设计最有价值的内容)。整个篇幅中有很多示例,是关于API设计一篇难得的好文章。

需要注意的是,这篇Wiki有一些内容并不完整,所以,可能会有一些阅读上的问题,我们对此做了一些相关的注释。

PS:翻译中肯定会有不足和不对之处,欢迎评论&交流;另译文源码在GitHub的这个仓库中,可以提交Issue/Fork后提交代码来建议/指正。

API设计原则

一致、易于掌握和强大的API是Qt最著名的优点之一。此文总结了我们在设计Qt风格API的过程中所积累的诀窍(know-how)。其中许多是通用准则;而其他的则更偏向于约定,遵循这些约定主要是为了与已有的API保持一致。

虽然这些准则主要用于对外的API(public API),但在设计对内的API(private API)时也推荐遵循相同的技巧(techniques),作为开发者之间协作的礼仪(courtesy)。

如有兴趣也可以读一下?Jasmin Blanchette?的Little Manual of API Design (PDF)?或是本文的前身?Matthias Ettrich?的Designing Qt-Style C++ APIs。

1. 好API的6个特质

API之于程序员就如同图形界面之于普通用户(end-user)。API中的『P』实际上指的是『程序员』(Programmer),而不是『程序』(Program),强调的是API是给程序员使用的这一事实。

在第13期Qt季刊,Matthias?的关于API设计的文章中提出了观点:API应该极简(minimal)且完备(complete)、语义清晰简单(have clear and simple semantics)、符合直觉(be intuitive)、易于记忆(be easy to memorize)和引导API使用者写出可读代码(lead to readable code)。

1.1 极简

极简的API是指每个class的public成员尽可能少,public的class也尽可能少。这样的API更易理解、记忆、调试和变更。

1.2 完备

完备的API是指期望有的功能都包含了。这点会和保持API极简有些冲突。如果一个成员函数放在错误的类中,那么这个函数的潜在用户就会找不到,这也是违反完备性的。

1.3 语义清晰简单

就像其他的设计一样,我们应该遵守最少意外原则(the principle of least surprise)。好的API应该可以让常见的事完成的更简单,并有可以完成不常见的事的可能性,但是却不会关注于那些不常见的事。解决的是具体问题;当没有需求时不要过度通用化解决方案。(举个例子,在Qt 3中,QMimeSourceFactory不应命名成QImageLoader并有不一样的API。)

1.4 符合直觉

就像计算机里的其他事物一样,API应该符合直觉。对于什么是符合直觉的什么不符合,不同经验和背景的人会有不同的看法。API符合直觉的测试方法:经验不很丰富的用户不用阅读API文档就能搞懂API,而且程序员不用了解API就能看明白使用API的代码。

1.5 易于记忆

为使API易于记忆,API的命名约定应该具有一致性和精确性。使用易于识别的模式和概念,并且避免用缩写。

1.6 引导API使用者写出可读代码

代码只写一次,却要多次的阅读(还有调试和修改)。写出可读性好的代码有时候要花费更多的时间,但对于产品的整个生命周期来说是节省了时间的。

最后,要记住的是,不同的用户会使用API的不同部分。尽管简单使用单个Qt类的实例应该符合直觉,但如果是要继承一个类,让用户事先看好文档是个合理的要求。

2. 静态多态

相似的类应该有相似的API。在继承(inheritance)合适时可以用继承达到这个效果,即运行时多态。然而多态也发生在设计阶段。例如,如果你用QProgressBar替换QSlider,或是用QString替换QByteArray,你会发现API的相似性使的替换很容易。这即是所谓的『静态多态』(static polymorphism)。

静态多态也使记忆API和编程模式更加容易。因此,一组相关的类有相似的API有时候比每个类都有各自的一套API更好。

一般来说,在Qt中,如果没有足够的理由要使用继承,我们更倾向于用静态多态。这样可以减少Qt?public类的个数,也使刚学习Qt的用户在翻看文档时更有方向感。

2.1 好的案例

QDialogButtonBoxQMessageBox,在处理按钮(addButton()、setStandardButtons()等等)上有相似的API,不需要继承某个QAbstractButtonBox类。

2.2 差的案例

QTcpSocketQUdpSocket都继承了QAbstractSocket,这两个类的交互行为的模式(mode of interaction)非常不同。似乎没有什么人以通用和有意义的方式用过QAbstractSocket指针(或者??以通用和有意义的方式使用QAbstractSocket指针)。

2.3 值得斟酌的案例

QBoxLayoutQHBoxLayoutQVBoxLayout的父类。好处:可以在工具栏上使用QBoxLayout,调用setOrientation()使其变为水平/垂直?;荡Γ阂嘁桓隼?,并且有可能导致用户写出这样没什么意义的代码,((QBoxLayout *)hbox)->setOrientation(Qt::Vertical)。

3. 基于属性的API

新的Qt类倾向于用『基于属性(property)的API』,例如:

QTimer timer;
timer.setInterval(1000);
timer.setSingleShot(true);
timer.start();

这里的?属性?是指任何的概念特征(conceptual attribute),是对象状态的一部分 —— 无论它是不是Q_PROPERTY。在说得通的情况下,用户应该可以以任何顺序设置属性,也就是说,属性之间应该是正交的(orthogonal)。例如,上面的代码可以写成:

QTimer timer;
timer.setSingleShot(true);
timer.setInterval(1000);
timer.start();

【译注】:正交性是指改变某个特性而不会影响到其他的特性。《程序员修炼之道》中讲了关于正交性的一个直升飞机坠毁的例子,讲得深入浅出很有画面感。

为了方便,也写成:

timer.start(1000);

类似地,对于QRegExp会是这样的代码:

QRegExp regExp;
regExp.setCaseSensitive(Qt::CaseInsensitive);
regExp.setPattern(".");
regExp.setPatternSyntax(Qt::WildcardSyntax);

为实现这种类型的API,需要借助底层对象的懒创建。例如,对于QRegExp的例子,在不知道模式语法(pattern syntax)的情况下,在setPattern()中去解释"."就为时过早了。

属性之间常常有关联的;在这种情况下,我们必须小心处理。思考下面的问题:当前的风格(style)提供了『默认的图标尺寸』属性 vs.?QToolButton的『iconSize』属性:

toolButton->setStyle(otherStyle);
toolButton->iconSize();    // returns the default for otherStyle
toolButton->setIconSize(QSize(52, 52));
toolButton->iconSize();    // returns (52, 52)
toolButton->setStyle(yetAnotherStyle);
toolButton->iconSize();    // returns (52, 52)

提醒一下,一旦设置了iconSize,设置就会一直保持,即使改变当前的风格。这?很好。但有的时候需要能重置属性。有两种方法:

  1. 传入一个特殊值(如QSize()、-1或者Qt::Alignment(0))来表示『重置』
  2. 提供一个明确的重置方法,如resetFoo()unsetFoo()

对于iconSize,使用QSize()(比如?QSize(–1, -1))来表示『重置』就够用了。

在某些情况下,getter方法返回的结果与所设置的值不同。例如,虽然调用了widget->setEnabled(true),但如果它的父widget处于disabled状态,那么widget->isEnabled()仍然返回的是false。这样是OK的,因为一般来说就是我们想要的检查结果(父widget处于disabled状态,里面的子widget也应该变为灰的不响应用户操作,就好像子widget自身处于disabled状态一样;与此同时,因为子widget记得在自己的内心深处是enabled状态的,只是一直等待着它的父widget变为enabled)。当然诸如这些都必须在文档中妥善地说明清楚。

4.?C++相关

4.1 值 vs. 对象

4.1.1 指针 vs. 引用

指针(pointer)还是引用(reference)哪个是最好的输出参数(out-parameters)?

void getHsv(int *h, int *s, int *v) const;
void getHsv(int &h, int &s, int &v) const;

大多数C++书籍推荐尽可能使用引用,基于一个普遍的观点:引用比指针『更加安全和优雅』。与此相反,我们在开发Qt时倾向于指针,因为指针让用户代码可读性更好。比较下面例子:

color.getHsv(&h, &s, &v);
color.getHsv(h, s, v);

只有第一行代码清楚表达出h、s、v参数在函数调用中非常有可能会被修改。

这也就是说,编译器并不喜欢『出参』,所你应该在新的API中避免使用『出参』,而是返回一个结构体,如下所示:

struct Hsv { int hue, saturation, value };
Hsv getHsv() const;

【译注】:函数的『入参』和『出参』的混用会导致 API 接口语义的混乱,所以,使用指针,在调用的时候,实参需要加上“&”,这样在代码阅读的时候,可以看到是一个『出参』,有利于代码阅读。(但是这样做,在函数内就需要判断指针是否为空的情况,因为引用是不需要判断的,所以,这是一种 trade-off)

另外,如果这样的参数过多的话,最好使用一个结构体来把数据打包,一方面,为一组返回值取个名字,另一方面,这样有利用接口的简单。

4.1.2 按常量引用传参 vs. 按值传参

如果类型大于16字节,按常量引用传参。

如果类型有重型的(non-trivial)拷贝构造函数(copy-constructor)或是重型的析构函数(destructor),按常量引用传参以避免执行这些函数。

对于其它的类型通常应该按值传参。

示例:

void setAge(int age);
void setCategory(QChar cat);
void setName(QLatin1String name);

// const-ref is much faster than running copy-constructor and destructor
void setAlarm(const QSharedPointer<Alarm> &alarm);

// QDate, QTime, QPoint, QPointF, QSize, QSizeF, QRect
// are good examples of other classes you should pass by value.

【译注】:这是传引用和传值的差别了,因为传值会有对像拷贝,传引用则不会。所以,如果对像的构造比较重的话(换句话说,就是对像里的成员变量需要的内存比较大),这就会影响很多性能。所以,为了提高性能,最好是传引用。但是如果传入引用的话,会导致这个对象可能会被改变。所以传入const reference。

4.2 虚函数

在C++中,当类的成员函数声明为virtual,主要是为了通过在子类重载此函数能够定制函数的行为。将函数声明为virtual的目的是为了让对这个函数已有的调用变成执行实际实例的代码路径。对于没有在类外部调用的函数声明成virtual,你应该事先非常慎重地思考过。

// QTextEdit in Qt 3: member functions that have no reason for being virtual
virtual void resetFormat();
virtual void setUndoDepth( int d );
virtual void setFormat( QTextFormat *f, int flags );
virtual void ensureCursorVisible();
virtual void placeCursor( const QPoint &pos;, QTextCursor **c = 0 );
virtual void moveCursor( CursorAction action, bool select );
virtual void doKeyboardAction( KeyboardAction action );
virtual void removeSelectedText( int selNum = 0 );
virtual void removeSelection( int selNum = 0 );
virtual void setCurrentFont( const QFont &f );
virtual void setOverwriteMode( bool b ) { overWrite = b; }

QTextEdit从Qt 3移植到Qt 4的时候,几乎所有的虚函数都被移除了。有趣的是(但在预料之中),并没有人对此有大的抱怨,为什么?因为Qt 3没用到QTextEdit的多态行为 —— 只有你会;简单地说,没有理由去继承QTextEdit并重写这些函数,除非你自己调用了这些方法。如果在Qt在外部你的应用程序你需要多态,你可以自己添加多态。

【译注】:『多态』的目的只不过是为了实践 —— 『依赖于接口而不是实现』,也就是说,接口是代码抽像的一个非常重要的方式(在Java/Go中都有专门的接口声明语法)。所以,如果没有接口抽像,使用『多态』的意义也就不大了,因为也就没有必要使用『虚函数』了。

4.2.1 避免虚函数

在Qt中,我们有很多理由尽量减少虚函数的数量。每一次对虚函数的调用会在函数调用链路中插入一个未掌控的节点(某种程度上使结果更无法预测),使得bug修复变得更复杂。用户在重写的虚函数中可以做很多疯狂的事:

  • 发送事件
  • 发送信号
  • 重新进入事件循环(例如,通过打开一个模态文件对话框)
  • 删除对象(即触发『delete this』)

还有其他很多原因要避免过度使用虚函数:

  • 添加、移动或是删除虚函数都带来二进制兼容问题(binary compatibility/BC)
  • 重载虚函数并不容易
  • 编译器几乎不能优化或内联(inline)对虚函数的调用
  • 虚函数调用需要查找虚函数表(v-table),这比普通函数调用慢了2到3倍
  • 虚函数使得类很难按值拷贝(尽管也可以按值拷贝,但是非?;炻也⑶也唤ㄒ檎庋觯?/li>

经验告诉我们,没有虚函数的类一般bug更少、维护成本也更低。

一般的经验法则是,除非我们以这个类作为工具集提供而且有很多用户来调用某个类的虚函数,否则这个函数九成不应该设计成虚函数。

【译注】:

  1. 使用虚函数时,你需要对编译器的内部行为非常清楚,否则,你会在使用虚函数时,觉得有好些『古怪』的问题发生。比如在创建数组对象的时候。
  2. 在C++中,会有一个基础类,这个基础类中已经实现好了很多功能,然后把其中的一些函数放给子类去修改和实现。这种方法在父类和子类都是一组开发人员维护时没有什么问题,但是如果这是两组开发人员,这就会带来很多问题了,就像Qt这样,子类完全无法控制,全世界的开发人员想干什么就干什么。所以,子类的代码和父类的代码在兼容上就会出现很多很多问题。所以,还是上面所说,其实,虚函数应该声明在接口的语义里(这就是设计模式的两个宗旨——依赖于接口,而不是实现;钟爱于组合,而不是继承。也是为什么Java和Go语言使用interface关键字的原因,C++在多态的语义上非常容易滥用)

4.2.2 虚函数 vs. 拷贝

多态对象(polymorphic objects)和值类型的类(value-type classes)两者很难协作好。

包含虚函数的类必须把析构函数声明为虚函数,以防止父类析构时没有清理子类的数据,导致内存泄漏。

如果要使一个类能够拷贝、赋值或按值比较,往往需要拷贝构造函数、赋值操作符(operator =)和相等操作符(operator ==)。

class CopyClass {
public:
    CopyClass();
    CopyClass(const CopyClass &other);
    ~CopyClass();
    CopyClass &operator =(const CopyClass &other);
    bool operator ==(const CopyClass &other) const;
    bool operator !=(const CopyClass &other) const;

    virtual void setValue(int v);
};

如果继承CopyClass这个类,预料之外的事就已经在代码时酝酿了。一般情况下,如果没有虚成员函数和虚析构函数,就不能创建出可以多态的子类。然而,如果存在虚成员函数和虚析构函数,这突然变成了要有子类去继承的理由,而且开始变得复杂了。起初认为只要简单声明上虚操作符重载函数(virtual operators)。?但其实是走上了一条混乱和毁灭之路(破坏了代码的可读性)??纯聪旅娴恼飧隼樱?/p>

class OtherClass {
public:
    const CopyClass &instance() const; // 这个方法返回的是什么?可以赋值什么?
};

(这部份还未完成)

【译注】:因为原文上说,这部份并没有完成,所以,我也没有搞懂原文具体也是想表达什么。不过,就标题而言,原文是想说,在多态的情况下拷贝对象所带来的问题??

4.3 关于const

C++的关键词const表明了内容不会改变或是没有副作用??梢杂τ糜诩虻サ闹?、指针及指针所指的内容,也可以作为一个特别的属性应用于类的成员函数上,表示成员函数不能修改对象的状态。

然而,const本身并没有提供太大的价值 —— 很多编程语言甚至没有类似const的关键词,但是却并没有因此产生问题。实际上,如果你不用函数重载,并在C++源代码用搜索并删除所有的const,几乎总能编译通过并且正常运行。尽量让使用的const保持实用有效,这点很重要。

让我们看一下在Qt的API设计中与const相关的场景。

4.3.1 输入参数:const指针

有输入指针参数的const成员函数,几乎总是const指针参数。

如果函数声明为const,意味着既没有副作用,也不会改变对象的可见状态。那为什么它需要一个没有const限定的输入参数呢?记住const类型的函数通常被其他const类型的函数调用,接收到的一般都是const指针(只要不主动const_cast,我们推荐尽量避免使用const_cast)

以前:

bool QWidget::isVisibleTo(QWidget *ancestor) const;
bool QWidget::isEnabledTo(QWidget *ancestor) const;
QPoint QWidget::mapFrom(QWidget *ancestor, const QPoint &pos) const;

QWidget声明了许多非const指针输入参数的const成员函数。注意,这些函数可以修改传入的参数,不能修改对象自己。使用这样的函数常常要借助const_cast转换。如果是const指针输入参数,就可以避免这样的转换了。

之后:

bool QWidget::isVisibleTo(const QWidget *ancestor) const;
bool QWidget::isEnabledTo(const QWidget *ancestor) const;
QPoint QWidget::mapFrom(const QWidget *ancestor, const QPoint &pos) const;

注意,我们在QGraphicsItem中对此做了修正,但是QWidget要等到Qt 5:

bool isVisibleTo(const QGraphicsItem *parent) const;
QPointF mapFromItem (const QGraphicsItem *item, const QPointF &point) const;

4.3.2 返回值:const值

调用函数返回的非引用类型的结果,称之为右值(R-value)。

非类(non-class)的右值总是无cv限定类型(cv-unqualified type)。虽然从语法上讲,加上const也可以,但是没什么意义,因为鉴于访问权限这些值是不能改变的。多数现代编译器在编译这样的代码时会提示警告信息。

【译注】:cv-qualified的类型(与cv-unqualified相反)是由const或者volatile或者volatile const限定的类型。详见cv (const and volatile) type qualifiers –?C++语言参考

当在类类型(class type)右值上添加const关键字,则禁止访问非const成员函数以及对成员的直接操作。

不加const则没有以上的限制,但几乎没有必要加上const,因为右值对象生存时间(life time)的结束一般在C++清理的时候(通俗的说,下一个分号地方),而对右值对象的修改随着右值对象的生存时间也一起结束了(也就是本条语句的执行完成的时候)。

示例:

struct Foo {
    void setValue(int v) { value = v; }
    int value;
};

Foo foo() {
    return Foo();
}

const Foo cfoo() {
    return Foo();
}

int main() {
    // The following does compile, foo() is non-const R-value which
    // can't be assigned to (this generally requires an L-value)
    // but member access leads to a L-value:
    foo().value = 1; // Ok, but temporary will be thrown away at the end of the full-expression.

    // The following does compile, foo() is non-const R-value which
    // can't be assigned to, but calling (even non-const) member
    // function is fine:
    foo().setValue(1); // Ok, but temporary will be thrown away at the end of the full-expression.

    // The following does _not_compile, foo() is ''const'' R-value
    // with const member which member access can't be assigned to:
    cfoo().value = 1; // Not ok.

    // The following does _not_compile, foo() is ''const'' R-value,
    // one cannot call non-const member functions:
    cfoo().setValue(1); // Not ok
}

【译注】:上述的代码说明,如果返回值不是const的,代码可以顺利编译通过,然而并没有什么卵用,因为那个临时对像马上就被抛弃了。所以,这样的无用的代码最好还是在编译时报个错,以免当时头脑发热想错了,写了一段没用但还以为有用的代码。

4.3.3 返回值:非const的指针还是有const的指针

谈到const函数应该返回非const的指针还是const指针这个话题时,多数人发现在C++中关于『const正确性』(const correctness)在概念上产生了分歧。?问题起源是:const函数本身不能修改对象自身的状态,却可以返回成员的非const指针。返回指针这个简单动作本身既不会影响整个对象的可见状态,当然也不会改变这个函数职责范围内涉及的状态。但是,这却使得程序员可以间接访问并修改对象的状态。

下面的例子演示了通过返回非const指针的const函数绕开const约定(constness)的诸多方式中的一种:

QVariant CustomWidget::inputMethodQuery(Qt::InputMethodQuery query) const {
    moveBy(10, 10); // doesn't compile!
    window()->childAt(mapTo(window(), rect().center()))->moveBy(10, 10); // compiles!
}

返回const指针的函数正是?;ひ员苊庹庑赡苁遣黄谕?没有预料到的)副作用,至少是在一定程度上。但哪个函数你会觉得更想返回const指针,或是不止一个函数?

若采用const正确(const-correct)的方法,每个返回某个成员的指针(或多个指向成员的指针)的const函数必须返回const指针。在实践中,很不幸这样的做法将导致无法使用的API:

QGraphicsScene scene;
// … populate scene

foreach (const QGraphicsItem *item, scene.items()) {
    item->setPos(qrand() % 500, qrand() % 500); // doesn't compile! item is a const pointer
}

QGraphicsScene::items()是一个const函数,顺着思考看起来这个函数只应该返回const指针。

在Qt中,我们几乎只有非const的使用模式。我们选择的是实用路子: 相比滥用非const指针返回类型带来的问题,返回const指针更可能招致过分使用const_cast的问题。

4.3.4 返回值:按值返回 还是 按const引用返回?

若返回的是对象的拷贝,那么返回const引用是更直接的方案; 然而,这样的做法限制了后面想要对这个类的重构(refactor)。 (以d-point的典型做法(idiom)为例,我们可以在任何时候改变Qt类在内存表示(memory representation);但却不能在不破坏二进制兼容性的情况下把改变函数的签名,返回值从const QFoo &变为QFoo。) 基于这个原因,除去对运行速度敏感(speed is critical)而重构不是问题的个别情形(例如,QList::at()),我们一般返回QFoo而不是const QFoo &。

【译注】:参看《Effective C++》中条款23:Don’t try to return a reference when you must return an object

4.4.5?const?vs. 对象的状态

const正确性(Const correctness)的问题就像C圈子中vi与emacs的讨论,因为这个话题在很多地方都存在分歧(比如基于指针的函数)。

但通用准则是const函数不能改变类的可见状态?!鹤刺坏囊馑际恰鹤陨硪约吧婕暗闹霸稹?。这并不是指非const函数能够改变自身的私有成员,也不是指const函数改变不了。而是指函数是活跃的并存在可见的副作用(visible side effects)。const函数一般没有任何可见的副作用,比如:

QSize size = widget->sizeHint(); // const
widget->move(10, 10); // not const

代理(delegate)负责在其它对象上绘制内容。 它的状态包括它的职责,因此包括在哪个对象做绘制这样的状态。 调用它的绘画行为必然会有副作用; 它改变了它绘制所在设备的外观(及其所关联的状态)。鉴于这些,paint()作为const函数并不合理。 进一步说,任何paint()QIconpaint()的视图函数是const函数也不合理。 没有人会从内部的const函数去调用QIcon::paint(),除非他想显式地绕开const这个特性。 如果是这种情况,使用const_cast会更好。

// QAbstractItemDelegate::paint is const
void QAbstractItemDelegate::paint(QPainter **painter, const QStyleOptionViewItem &option, const QModelIndex &index) const

// QGraphicsItem::paint is not const
void QGraphicsItem::paint(QPainter *painter, const QStyleOptionGraphicsItem option, QWidget *widget)

const关键字并不能按你期望的样子起作用。应该考虑将其移除而不是去重载const/非const函数。

5.?API的语义和文档

当传值为-1的参数给函数,函数会是什么行为?有很多类似的问题……

是警告、致命错误还是其它?

API需要的是质量保证。API第一个版本一定是不对的;必须对其进行测试。 以阅读使用API的代码的方式编写用例,且验证这样代码是可读的。

还有其他的验证方法,比如

  • 让别人使用API(看了文档或是先不看文档都可以)
  • 给类写文档(包含类的概述和每个函数)

6. 命名的艺术

命名很可能是API设计中最重要的一个问题。类应该叫什么名字?成员函数应该叫什么名字?

6.1 通用的命名规则

有几个规则对于所有类型的命名都等同适用。第一个,之前已经提到过,不要使用缩写。即使是明显的缩写,比如把previous缩写成prev,从长远来看是回报是负的,因为用户必须要记住缩写词的含义。

如果API本身没有一致性,之后事情自然就会越来越糟;例如,Qt 3?中同时存在activatePreviousWindow()fetchPrev()。恪守『不缩写』规则更容易地创建一致性的API。

另一个时重要但更微妙的准则是在设计类时应该保持子类名称空间的干净。在Qt 3中,此项准则并没有一直遵循。以QToolButton为例对此进行说明。如果调用QToolButton的?name()、caption()、text()或者textLabel(),你觉得会返回什么?用Qt设计器在QToolButton上自己先试试吧:

  • name属性是继承自QObject,返回内部的对象名称,用于调试和测试。
  • caption属性继承自QWidget,返回窗口标题,对QToolButton来说毫无意义,因为它在创建的时候parent就存在了。
  • text函数继承自QButton,一般用于按钮。当useTextLabel不为true,才用这个属性。
  • textLabel属性在QToolButton内声明,当useTextLabeltrue时显示在按钮上。

为了可读性,在Qt 4中QToolButtonname属性改成了objectName,caption改成了windowTitle,删除了textLabel属性因为和text属性相同。

当你找不到好的命名时,写文档也是个很好方法:要做的就是尝试为各个条目(item)(如类、方法、枚举值等等)写文档,并用写下的第一句话作为启发。如果找不到一个确切的命名,往往说明这个条目是不该有的。如果所有尝试都失败了,并且你坚信这个概念是合理的,那么就发明一个新名字。像widget、event、focus和buddy这些命名就是在这一步诞生的。

【译注】:写文档是一个非常好的习惯。写文档的过程其实就是在帮你梳理你的编程思路。很多时候,文档写着写着你就会发现要去改代码去了。除了上述的好处多,写文档还有更多的好处。比如,在写文档的过程中,你发现文字描述过于复杂了,这表明着你的代码或逻辑是复杂的,这就倒逼你去重构你的代码。所以 ——?写文档其实就是写代码。

6.2 类的命名

识别出类所在的分组,而不是为每个类都去找个完美的命名。例如,所有Qt 4的能感知模型(model-aware)的item view,类后缀都是ViewQListView、QTableView、QTreeView),而相应的基于item(item-based)的类后缀是WidgetQListWidget、QTableWidget、QTreeWidget)。

6.3 枚举类型及其值的命名

声明枚举类型时,需要记住在C++中枚举值在使用时不会带上类型(与Java、C#不同)。下面的例子演示了枚举值命名得过于通用的危害:

namespace Qt
{
    enum Corner { TopLeft, BottomRight, ... };
    enum CaseSensitivity { Insensitive, Sensitive };
    ...
};

tabWidget->setCornerWidget(widget, Qt::TopLeft);
str.indexOf("$(QTDIR)", Qt::Insensitive);

在最后一行,Insensitive是什么意思?命名枚举类型的一个准则是在枚举值中至少重复此枚举类型名中的一个元素:

namespace Qt
{
    enum Corner { TopLeftCorner, BottomRightCorner, ... };
    enum CaseSensitivity { CaseInsensitive, CaseSensitive };
    ...
};

tabWidget->setCornerWidget(widget, Qt::TopLeftCorner);
str.indexOf("$(QTDIR)", Qt::CaseInsensitive);

当对枚举值进行或运算并作为某种标志(flag)时,传统的做法是把或运算的结果保存在int型的值中,但这不是类型安全的。Qt 4提供了一个模板类QFlags,其中的T是枚举类型。为了方便使用,Qt用typedef重新定义了QFlag类型,所以可以用Qt::Alignment代替QFlags。

习惯上,枚举类型命名用单数形式(因为它一次只能『持有』一个flag),而持有多个『flag』的类型用复数形式,例如:

enum RectangleEdge { LeftEdge, RightEdge, ... };
typedef QFlags<RectangleEdge> RectangleEdges;

在某些情形下,持有多个『flag』的类型命名用单数形式。对于这种情况,持有的枚举类型名称要求是以Flag为后缀:

enum AlignmentFlag { AlignLeft, AlignTop, ... };
typedef QFlags<AlignmentFlag> Alignment;

6.4 函数和参数的命名

函数命名的第一准则是可以从函数名看出来此函数是否有副作用。在Qt 3中,const函数QString::simplifyWhiteSpace()违反了此准则,因为它返回了一个QString而不是按名称暗示的那样,改变调用它的QString对象。在Qt 4中,此函数重命名为QString::simplified()。

虽然参数名不会出现在使用API的代码中,但是它们给程序员提供了重要信息。因为现代的IDE都会在写代码时显示参数名称,所以值得在头文件中给参数起一个恰当的名字并在文档中使用相同的名字。

6.5 布尔类型的getter与setter方法的命名

bool属性的getter和setter方法命名总是很痛苦。getter应该叫做checked()还是isChecked()?scrollBarsEnabled()还是areScrollBarEnabled()?

Qt 4中,我们套用以下准则为getter命名:

  • 形容词以is为前缀,例子:
    • isChecked()
    • isDown()
    • isEmpty()
    • isMovingEnabled()
  • 然而,修饰名词的形容词没有前缀:
    • scrollBarsEnabled(),而不是areScrollBarsEnabled()
  • 动词没有前缀,也不使用第三人称(-s):
    • acceptDrops(),而不是acceptsDrops()
    • allColumnsShowFocus()
  • 名词一般没有前缀:
    • autoCompletion(),而不是isAutoCompletion()
    • boundaryChecking()
  • 有的时候,没有前缀容易产生误导,这种情况下会加上is前缀:
    • isOpenGLAvailable(),而不是openGL()
    • isDialog(),而不是dialog()
      (一个叫做dialog()的函数,一般会被认为是返回QDialog。)

setter的名字由getter衍生,去掉了前缀后在前面加上了set;例如,setDown()setScrollBarsEnabled()。

7. 避免常见陷阱

7.1 简化的陷阱

一个常见的误解是:实现需要写的代码越少,API就设计得越好。应该记?。捍胫换嵝瓷霞复?,却要被反复阅读并理解。例如:

QSlider *slider = new QSlider(12, 18, 3, 13, Qt::Vertical, 0, "volume");

这段代码比下面的读起来要难得多(甚至写起来也更难):

QSlider *slider = new QSlider(Qt::Vertical);
slider->setRange(12, 18);
slider->setPageStep(3);
slider->setValue(13);
slider->setObjectName("volume");

【译注】:在有IDE的自动提示的支持下,后者写起来非常方便,而前者还需要看相应的文档。

7.2 布尔参数的陷阱

布尔类型的参数总是带来无法阅读的代码。给现有的函数增加一个bool型的参数几乎永远是一种错误的行为。仍以Qt为例,repaint()有一个bool类型的可选参数用于指定背景是否被擦除??梢孕闯稣庋拇耄?/p>

widget->repaint(false);

初学者很可能是这样理解的,『不要重新绘制!』,能有多少Qt用户真心知道下面3行是什么意思:

widget->repaint();
widget->repaint(true);
widget->repaint(false);

更好的API设计应该是这样的:

widget->repaint();
widget->repaintWithoutErasing();

在Qt 4中,我们通过移除了重新绘制(repaint)而不擦除widget的能力来解决了此问题。Qt 4的双缓冲使这种特性被废弃。

还有更多的例子:

widget->setSizePolicy(QSizePolicy::Fixed, QSizePolicy::Expanding, true);
textEdit->insert("Where's Waldo?", true, true, false);
QRegExp rx("moc_***.c??", false, true);

一个明显的解决方案是bool类型改成枚举类型。我们在Qt 4的QString中就是这么做的。对比效果如下:

str.replace("%USER%", user, false);               // Qt 3
str.replace("%USER%", user, Qt::CaseInsensitive); // Qt 4

【译注】:关于这个条目可以看看 CoolShell 这篇文章一些展开的讨论:?千万不要把 BOOL 设计成函数参数。

8. 案例研究

8.1?QProgressBar

为了展示上文各种准则的实际应用。我们来研究一下Qt 3中QProgressBar的API,并与Qt 4中对应的API作比较。在Qt 3中:

class QProgressBar : public QWidget
{
    ...
public:
    int totalSteps() const;
    int progress() const;

    const QString &progressString() const;
    bool percentageVisible() const;
    void setPercentageVisible(bool);

    void setCenterIndicator(bool on);
    bool centerIndicator() const;

    void setIndicatorFollowsStyle(bool);
    bool indicatorFollowsStyle() const;

public slots:
    void reset();
    virtual void setTotalSteps(int totalSteps);
    virtual void setProgress(int progress);
    void setProgress(int progress, int totalSteps);

protected:
    virtual bool setIndicator(QString &progressStr,
                              int progress,
                              int totalSteps);
    ...
};

该API相当的复杂和不一致;例如,reset()、setTotalSteps()、setProgress()是紧密联系的,但方法的命名并没明确地表达出来。

改善此API的关键是抓住QProgressBar与Qt 4的QAbstractSpinBox及其子类QSpinBox、QSlider、QDail之间的相似性。怎么做?把progress、totalSteps替换为minimum、maximumvalue。增加一个valueChanged()消息,再增加一个setRange()函数。

进一步可以观察到progressString、percentageindicator其实是一回事,即是显示在进度条上的文本。通常这个文本是个百分比,但是可通过setIndicator()设置为任何内容。以下是新的API:

virtual QString text() const;
void setTextVisible(bool visible);
bool isTextVisible() const;

默认情况下,显示文本是百分比指示器(percentage indicator),通过重写text()方法来定制行为。

Qt 3的setCenterIndicator()setIndicatorFollowsStyle()是两个影响对齐方式的函数。他们可被一个setAlignment()函数代替:

void setAlignment(Qt::Alignment alignment);

如果开发者未调用setAlignment(),那么对齐方式由风格决定。对于基于Motif的风格,文字内容在中间显示;对于其他风格,在右侧显示。

下面是改善后的QProgressBar API:

class QProgressBar : public QWidget
{
    ...
public:
    void setMinimum(int minimum);
    int minimum() const;
    void setMaximum(int maximum);
    int maximum() const;
    void setRange(int minimum, int maximum);
    int value() const;

    virtual QString text() const;
    void setTextVisible(bool visible);
    bool isTextVisible() const;
    Qt::Alignment alignment() const;
    void setAlignment(Qt::Alignment alignment);

public slots:
    void reset();
    void setValue(int value);

signals:
    void valueChanged(int value);
    ...
};

8.2?QAbstractPrintDialog?&?QAbstractPageSizeDialog

Qt 4.0有2个幽灵类QAbstractPrintDialogQAbstractPageSizeDialog,作为?QPrintDialogQPageSizeDialog类的父类。这2个类完全没有用,因为Qt的API没有是QAbstractPrint-或是-PageSizeDialog指针作为参数并执行操作。通过篡改qdoc(Qt文档),我们虽然把这2个类隐藏起来了,却成了无用抽象类的典型案例。

这不是说,?的抽象是错的,QPrintDialog应该是需要有个工厂或是其它改变的机制 —— 证据就是它声明中的#ifdef QTOPIA_PRINTDIALOG。

8.3?QAbstractItemModel

关于模型/视图(model/view)问题的细节在相应的文档中已经说明得很好了,但作为一个重要的总结这里还需要强调一下:抽象类不应该仅是所有可能子类的并集(union)。这样『合并所有』的父类几乎不可能是一个好的方案。QAbstractItemModel就犯了这个错误 —— 它实际上就是个QTreeOfTablesModel,结果导致了错综复杂(complicated)的API,而这样的API要让?所有本来设计还不错的子类?去继承。

仅仅增加抽象是不会自动就把API变得更好的。

8.4?QLayoutIterator?&?QGLayoutIterator

在Qt 3,创建自定义的布局类需要同时继承QLayoutQGLayoutIterator(命名中的G是指Generic(通用))。QGLayoutIterator子类的实例指针会包装成QLayoutIterator,这样用户可以像和其它的迭代器(iterator)类一样的方式来使用。通过QLayoutIterator可以写出下面这样的代码:

QLayoutIterator it = layout()->iterator();
QLayoutItem **child;
while ((child = it.current()) != 0) {
    if (child->widget() == myWidget) {
        it.takeCurrent();
        return;
    }
    ++it;
}

在Qt 4,我们干掉了QGLayoutIterator类(以及用于盒子布局和格子布局的内部子类),转而是让QLayout的子类重写itemAt()、takeAt()count()。

8.5?QImageSink

Qt 3有一整套类用来把完成增量加载的图片传递给一个动画 ——?QImageSource/Sink/QASyncIO/QASyncImageIO。由于这些类之前只是用于启用动画的QLabel,完全过度设计了(overkill)。

从中得到的教训就是:对于那些未来可能的还不明朗的需求,不要过早地增加抽象设计。当需求真的出现时,比起一个复杂的系统,在简单的系统新增需求要容易得多。


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/18024.html/feed 21
Linux PID 1 和 Systemd http://www.chinamxjy.com/articles/17998.html http://www.chinamxjy.com/articles/17998.html#comments Sun, 16 Jul 2017 13:40:55 +0000 http://www.chinamxjy.com/?p=17998 Read More Read More

]]>
要说清 Systemd,得先从Linux操作系统的启动说起。Linux 操作系统的启动首先从 BIOS 开始,然后由 Boot Loader 载入内核,并初始化内核。内核初始化的最后一步就是启动 init 进程。这个进程是系统的第一个进程,PID 为 1,又叫超级进程,也叫根进程。它负责产生其他所有用户进程。所有的进程都会被挂在这个进程下,如果这个进程退出了,那么所有的进程都被 kill 。如果一个子进程的父进程退了,那么这个子进程会被挂到 PID 1 下面。(注:PID 0 是内核的一部分,主要用于内进换页,参看:Process identifier

SysV Init

PID 1 这个进程非常特殊,其主要就任务是把整个操作系统带入可操作的状态。比如:启动 UI – Shell 以便进行人机交互,或者进入 X 图形窗口。传统上,PID 1 和传统的 Unix System V 相兼容的,所以也叫 sysvinit,这是使用得最悠久的 init 实现。Unix System V 于1983年 release。

sysvint 下,有好几个运行模式,又叫 runlevel。比如:常见的 3 级别指定启动到多用户的字符命令行界面,5 级别指定启起到图形界面,0 表示关机,6 表示重启。其配置在 /etc/inittab 文件中。

与此配套的还有 /etc/init.d//etc/rc[X].d,前者存放各种进程的启停脚本(需要按照规范支持 start,stop子命令),后者的 X 表示不同的 runlevel 下相应的后台进程服务,如:/etc/rc3.d 是 runlevel=3 的。 里面的文件主要是 link 到 ?/etc/init.d/?里的启停脚本。其中也有一定的命名规范:S 或 K 打头的,后面跟一个数字,然后再跟一个自定义的名字,如:S01rsyslog,S02ssh。S 表示启动,K表示停止,数字表示执行的顺序。

UpStart

Unix 和 Linux 在 sysvint 运作多年后,大约到了2006年的时候,Linux内核进入2.6时代,Linux有了很多更新。并且,Linux开始进入桌面系统,而桌面系统和服务器系统不一样的是,桌面系统面临频繁重启,而且,用户会非常频繁的使用硬件的热插拔技术。于是,这些新的场景,让 sysvint 受到了很多挑战。

比如,打印机需要CUPS等服务进程,但是如果用户没有打机印,启动这个服务完全是一种浪费,而如果不启动,如果要用打印机了,就无法使用,因为sysvint 没有自动检测的机制,它只能一次性启动所有的服务。另外,还有网络盘挂载的问题。在 /etc/fstab 中,负责硬盘挂载,有时候还有网络硬盘(NFS 或 iSCSI)在其中,但是在桌面机上,有很可能开机的时候是没有网络的, 于是网络硬盘都不可以访问,也无法挂载,这会极大的影响启动速度。sysvinit 采用 netdev 的方式来解决这个问题,也就是说,需要用户自己在 /etc/fstab 中给相应的硬盘配置上 netdev 属性,于是 sysvint 启动时不会挂载它,只有在网络可用后,由专门的 netfs 服务进程来挂载。这种管理方式比较难以管理,也很容易让人掉坑。

所以,Ubuntu 开发人员在评估了当时几个可选的 init 系统后,决定重新设计这个系统,于是,这就是我们后面看到的 upstart 。 upstart 基于事件驱动的机制,把之前的完全串行的同步启动服务的方式改成了由事件驱动的异步的方式。比如:如果有U盘插入,udev 得到通知,upstart 感知到这个事件后触发相应的服务程序,比如挂载文件系统等等。因为使用一个事件驱动的玩法,所以,启动操作系统时,很多不必要的服务可以不用启动,而是等待通知,lazy 启动。而且事件驱动的好处是,可以并行启动服务,他们之间的依赖关系,由相应的事件通知完成。

upstart 有着很不错的设计,其中最重要的两个概念是 Job 和 Event。

Job 有一般的Job,也有service的Job,并且,upstart 管理了整个 Job 的生命周期,比如:Waiting, Starting, pre-Start, Spawned, post-Start, Running, pre-Stop, Stopping, Killed, post-Stop等等,并维护着这个生命周期的状态机。

Event 分成三类,signal, methodhooks。signal 就是异步消息,method 是同步阻塞的。hooks 也是同步的,但介于前面两者之间,发出hook事件的进程必须等到事件完成,但不检查是否成功。

但是,upstart 的事件非常复杂,也非常纷乱,各种各样的事件(事件没有归好类)导致有点凌乱。不过因为整个事件驱动的设计比之前的 sysvinit 来说好太多,所以,也深得欢迎。

Systemd

直到2010的有一天,一个在 RedHat工作的工程师?Lennart Poettering?和?Kay Sievers?,开始引入了一个新的 init 系统—— systemd。这是一个非常非常有野心的项目,这个项目几乎改变了所有的东西,systemd 不但想取代已有的 init 系统,而且还想干更多的东西。

Lennart 同意 upstart 干的不错,代码质量很好,基于事件的设计也很好。但是他觉得 upstart 也有问题,其中最大的问题还是不够快,虽然 upstart 用事件可以达到一定的启动并行度,但是,本质上来说,这些事件还是会让启动过程串行在一起。 ?如:NetworkManager 在等 D-Bus 的启动事件,而 D-Bus 在等 syslog 的启动事件。

Lennart 认为,实现上来说,upstart 其实是在管理一个逻辑上的服务依赖树,但是这个服务依赖树在表现形式上比较简单,你只需要配置——“启动 B好了就启动A”或是“停止了A后就停止B”这样的规则。但是,Lennart 说,这种简单其实是有害的(this simplification is actually detrimental)。他认为,

  • 从一个系统管理的角度出来,他一开始会设定好整个系统启动的服务依赖树,但是这个系统管理员要人肉的把这个本来就非常干净的服务依整树给翻译成计算机看的懂的 Event/Action 形式,而且 Event/Action 这种配置方式是运行时的,所以,你需要运行起来才知道是什么样的。
  • Event逻辑从头到脚到处都是,这个事件扩大了运维的复杂度,还不如之前的 sysvint。 也就是说,当用户配置了 “启动 D-Bus 后请启动 NetworkManager”, 这个 upstart 可以干,但是反过来,如果,用户启动 NetworkManager,我们应该先去启动他的前置依赖 D-Bus,然而你还要配置相应的反向 Event。本来,我只需要配置一条依赖的,结果现在我要配置很多很多情况下的Event。
  • 最后,upstart 里的 Event 的并不标准,很混乱,没有良好的定义。比如:既有,进程启动,运行,停止的事件,也有USB设备插入、可用、拔出的事件,还有文件系统设备being mounted、 mounted 和 umounted 的事件,还有AC电源线连接和断开的事件。你会发现,这进程启停的、USB的、文件系统的、电源线的事件,看上去长得很像, 但是没有被标准化抽像出来掉,因为绝大多数的事件都是三元组:start, condition, stop 。这种概念设计模型并没有在 upstart 中出现。因为 upstart 被设计为单一的事件,而忽略了逻辑依赖。

当然,如果 systemd 只是解决 upstart 的问题,他就改造 upstart 就好了,但是 Lennart 的野心不只是想干个这样的事,他想干的更多。

首先,systemd 清醒的认识到了 init 进程的首要目标是要让用户快速的进入可以操作OS的环境,所以,这个速度一定要快,越快越好,所以,systemd 的设计理念就是两条:

  • To start?less.
  • And to start?more?in?parallel.

也就是说,按需启动,能不启动就不启动,如果要启动,能并行启动就并行启动,包括你们之间有依赖,我也并行启动。按需启动还好理解,那么,有依赖关系的并行启动,它是怎么做到的?这里,systemd 借鉴了 MacOS 的 Launchd 的玩法(在Youtube上有一个分享——Launchd: One Program to Rule them All,在苹果的开源网站上也有相关的设计文档——About Daemons and Services

要解决这些依赖性,systemd 需要解决好三种底层依赖—— Socket, D-Bus ,文件系统。

  • Socket依赖。如果服务C依赖于服务S的socket,那么就要先启动S,然后再启动C,因为如果C启动时找不到S的Socket,那么C就会失败。systemd 可以帮你在S还没有启动好的时候,建立一个socket,用来接收所有的C的请求和数据,并缓存之,一旦S全部启动完成,把systemd替换好的这个缓存的数据和Socket描述符替换过去。

 

  • D-Bus依赖。D-Bus 全称 Desktop Bus,是一个用来在进程间通信的服务。除了用于用户态进程和内核态进程通信,也用于用户态的进程之前。现在,很多的现在的服务进程都用 D-Bus 而不是Socket来通信。比如:NetworkManager 就是通过 D-Bus 和其它服务进程通讯的,也就是说,如果一个进程需要知道网络的状态,那么就必需要通过 D-Bus 通信。D-Bus 支持 “Bus Activation”的特性。也就是说,A要通过 D-Bus 服务和B通讯,但是B没有启动,那么 D-Bus 可以把B起来,在B启动的过程中,D-Bus 帮你缓存数据。systemd 可以帮你利用好这个特性来并行启动 A 和 B。

 

  • 文件系统依赖。系统启动过程中,文件系统相关的活动是最耗时的,比如挂载文件系统,对文件系统进行磁盘检查(fsck),磁盘配额检查等都是非常耗时的操作。在等待这些工作完成的同时,系统处于空闲状态。那些想使用文件系统的服务似乎必须等待文件系统初始化完成才可以启动。systemd 参考了 autofs 的设计思路,使得依赖文件系统的服务和文件系统本身初始化两者可以并发工作。autofs 可以监测到某个文件系统挂载点真正被访问到的时候才触发挂载操作,这是通过内核 automounter ??榈闹С侄迪值?。比如一个 open() 系统调用作用在某个文件系统上的时候,而这个文件系统尚未执行挂载,此时 open() 调用被内核挂起等待,等到挂载完成后,控制权返回给 open() 系统调用,并正常打开文件。这个过程和 autofs 是相似的。

 

下图来自 Lennart 的演讲里的一页PPT,展示了不同 init 系统的启动。

除此之外,systemd 还在启动时管理好了一些下面的事。

用C语言取代传统的脚本式的启动。前面说过,sysvint/etc/rcX.d 下的各种脚本启动。然而这些脚本中需要使用 awk, sed, grep, find, xargs 等等这些操作系统的命令,这些命令需要生成进程,生成进程的开销很大,关键是生成完这些进程后,这个进程就干了点屁大的事就退了?;痪浠八稻褪?,我操作系统干了那么多事为你拉个进程起来,结果你就把个字串转成小写就退了,把我操作系统当什么了?

在正常的一个 sysvinit 的脚本里,可能会有成百上千个这样的命令。所以,慢死。因此,systemd 全面用 C 语言全部取代了。一般来说,sysvinit 下,操作系统启动完成后,用 echo $$ 可以看到,pid 被分配到了上千的样子,而 systemd 的系统只是上百。

另外,systemd 是真正一个可以管住服务进程的——可以跟踪上服务进程所fork/exec出来的所有进程。

  • 我们知道, 传统 Unix/Linux 的 Daemon 服务进程的最佳实践基本上是这个样子的 (具体过程可参看这篇文章“SysV Daemon”)——
    1. 进程启动时,关闭所有的打开的文件描述符(除了标准描述符0,1,2),然后重置所有的信号处理。
    2. 调用 fork() 创建子进程,在子进程中 setsid(),然后父进程退出(为了后台执行)
    3. 在子进程中,再调用一次 fork(),创建孙子进程,确定没有交互终端。然后子进程退出。
    4. 在孙子进程中,把标准输入标准输出标准错误都连到 /dev/null 上,还要创建 pid 文件,日志文件,处理相关信号 ……
    5. 最后才是真正开始提供服务。

 

  • 在上面的这个过程中,服务进程除了两次 fork 外还会 fork 出很多很多的子进程(比如说一些Web服务进程,会根据用户的请求链接来 fork 子进程),这个进程树是相当难以管理的,因为,一旦父进程退出来了,子进程就会被挂到 PID 1下,所以,基本上来说,你无法通过服务进程自已给定的一个pid文件来找到所有的相关进程(这个对开发者的要求太高了),所以,在传统的方式下用脚本启停服务是相当相当的 Buggy 的,因为无法做对所有的服务生出来的子子孙孙做到监控。

 

  • 为了解决这个问题,upstart 通过变态的 strace 来跟踪进程中的 fork()exec()exit() 等相关的系统调用。这种方法相当笨拙。 systemd 使用了一个非常有意思的玩法来 tracking 服务进程生出来的所有进程,那就是用 cgroup (我在 Docker 的基础技术“cgroup篇”中讲过这个东西)。cgroup主要是用来管理进程组资源配额的事,所以,无论服务如何启动新的子进程,所有的这些相关进程都会同属于一个 cgroup,所以,systemd 只需要简单的去遍历一下相应的 cgroup 的那个虚文件系统目录下的文件,就可以正确的找到所有的相关进程,并将他们一一停止。

 

另外,systemd 简化了整个 daemon 开发的过程:

  • 不需要两次 fork(),只需要实现服务本身的主逻辑就可以了。
  • 不需要 setsid(),systemd 会帮你干
  • 不需要维护 pid文件,systemd 会帮处理。
  • 不需要管理日志文件或是使用syslog,或是处理HUP的日志reload信号。把日志打到 stderr 上,systemd 帮你管理。
  • 处理 SIGTERM 信号,这个信号就是正确退出当前服务,不要做其他的事。
  • ……

除此之外,systemd?还能——

  • 自动检测启动的服务间有没有环形依赖。
  • 内建 autofs 自动挂载管理功能。
  • 日志服务。systemd?改造了传统的 syslog 的问题,采用二进制格式保存日志,日志索引更快。
  • 快照和恢复。对当前的系统运行的服务集合做快照,并可以恢复。
  • ……

还有好多好多,他接管很多很多东西,于是就让很多人不爽了,因为他在干了很多本不属于 PID 1 的事。

Systemd 争论和八卦

于是 systemd 这个东西成了可能是有史以来口水战最多的一个开源软件了。systemd 饱受各种争议,最大的争议就是他破坏了 Unix 的设计哲学(相关的哲学可以读一下《Unix编程艺术》),干了一个大而全而且相当复杂的东西。当然,Lennart 并不同意这样的说法,他后来又写一篇blog “The Biggest Myths”来解释 systemd 并不是这样的,大家可以前往一读。

这个争议大到什么样子呢?2014 年,Debian Linux 因为想准备使用 systemd 来作为标准的 init 守护进程来替换 sysvinit 。而围绕这个事的争论达到了空前的热度,争论中充满着仇恨,systemd 的支持者和反对者都在互相辱骂,导致当时 Debian 阵营开始分裂?;褂腥烁?Lennart 发了死亡威胁的邮件,用比特币雇凶买杀手,扬言要取他的性命,在Youbute上传了侮辱他的歌曲,在IRC和各种社交渠道上给他发下流和侮辱性的消息。这已经不是争议了,而是一种不折不扣的仇恨!

于是,Lennart 在 Google Plus 上发了贴子,批评整个 Linux 开源社区和 Linus 本人。他大意说,

这个社区太病态了,全是 ass holes,你们不停用各种手段在各种地方用不同的语言和方式来侮辱和漫骂我。我还是一个年轻人,我从来没有经历过这样的场面,但是今天我已经对这种场面很熟悉了。我有时候说话可能不准确,但是我不会像他样那样说出那样的话,我也没有被这些事影响,因为我脸皮够厚,所以,为什么我可以在如何大的反对声面前让?systemd 成功,但是,你们 Linux 社区太可怕了。你们里面的有精神病的人太多了。另外,对于Linus Torvalds,你是这个社区的 Role Model,但可惜你是一个 Bad Role Model,你在社区里的刻薄和侮辱性的言行,基本从一定程度上鼓励了其它人跟你一样,当然,并不只是你一个人的问题,而是在你周围聚集了一群和你一样的这样干的人。送你一句话——?A fish rots from the head down !一条鱼是从头往下腐烂的……

这篇契文很长,喜欢八卦的同学可以前往一读。感受一下 Lennart 当时的心态(我觉得能算上是非常平稳了)。

Linus也在被一媒体问起 systemd 这个事来(参看“Torvalds says he has no strong opinions on systemd”),Linus在采访里说,

我对 systemd 和 Lennart 的贴子没有什么强烈的想法。虽然,传统的 Unix 设计哲学—— “Do one thing and Do it well”,很不错,而且我们大多数人也实践了这么多年,但是这并不代表所有的真实世界。在历史上,也不只有systemd 这么干过。但是,我个人还是 old-fashioned 的人,至少我喜欢文本式的日志,而不是二进制的日志。但是 systemd 没有必要一定要有这样的品味。哦,我说细节了……

今天,systemd 占据了几乎所有的主流的 Linux 发行版的默认配置,包括:Arch Linux、CentOS、CoreOS、Debian、Fedora、Megeia、OpenSUSE、RHEL、SUSE企业版和 Ubuntu。而且,对于 CentOS, CoreOS, Fedora, RHEL, SUSE这些发行版来说,不能没有 systemd。(Ubuntu 还有一个不错的wiki – Systemd for Upstart Users?阐述了如何在两者间切换)

 

其它

还记得在《缓存更新的套路》一文中,我说过,如果你要做好架构,首先你得把计算机体系结构以及很多老古董的基础技术吃透了。因为里面会有很多可以借鉴和相通的东西。那么,你是否从这篇文章里看到了一些有分布式架构相似的东西?

比如:从 sysvinitupstart 再到 systemd,像不像是服务治理?Linux系统下的这些服务进程,是不是很像分布式架构中的微服务?还有那个D-Bus,是不是很像SOA里的ESB?而 init 系统是不是很像一个控制系统?甚至像一个服务编排(Service Orchestration)系统?

分布式系统中的服务之间也有很多依赖,所以,在启动一个架构的时候,如果我们可以做到像 systemd 那样并行启动的话,那么是不是就像是一个微服务的玩法了?

嗯,你会发现,技术上的很多东西是相通的,也是互相有对方的影子,所以,其实技术并不多。关键是我们学在了表面还是看到了本质。

 

延伸阅读

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/17998.html/feed 39
我看绩效考核 http://www.chinamxjy.com/articles/17972.html http://www.chinamxjy.com/articles/17972.html#comments Sun, 09 Jul 2017 10:03:00 +0000 http://www.chinamxjy.com/?p=17972 Read More Read More

]]>
(本来,这篇文章应该在5月份完成,我拖延症让我今天才完成)

前些天,有几个网友找我谈绩效考核的事,都是在绩效上被差评的朋友。在大致了解情况后,我发现他们感到沮丧和郁闷的原因,不全是自己没有做好事情,他们对于自己没有做好公司交给的事,一方面,持一些疑义,因为我很明显地感到他们和公司对一件是否做好的标准定义有误差,另一方面,他们对于自己的工作上的问题也承认。不过,让他们更多感到沮丧的原因则是,公司、经理或HR和他们的谈话,让他们感觉整个人都被完全否定了,甚至有一种被批斗的感觉。这个感觉实在是太糟糕了。

因为我也有相似的经历,所以,我想在这里写下一篇文章,谈谈自己的对一些绩效考核的感受。先放出我的两个观点:

1)制定目标和绩效,目的不是用来考核人的,而用来改善提高组织和人员业绩和效率的。

2)人是复杂的,人是有状态波动的,任何时候都不应该轻易否定人,绩效考核应该考核的是事情,而不是人。

我个人比较坚持的认为——绩效分应该打给项目,打给产品,打给部门,打给代码,而不是打给人。然而现在的管理体制基本上都是打给人,而很多根本不擅长管理的经理和HR以及很多不会独立思考的吃瓜群众基本上都会把矛头指向个人,所以,当然会有开批斗会的感觉。

 

举几个例子

为了讲清楚我的上述观点,请让我先铺垫一下,先说几个例子吧,韩寒的例子我就不说了。

苏步青同学在小学时成绩很糟糕,全班倒数第一。

华罗庚同学上学时数学还考不及格,要不是王维克老师的鼓励并让他爱上了数学,他可能也就完全埋没了。

郑渊洁上学时,老师要求写《早起的鸟有虫子吃》,郑渊洁唱反调写《早起的虫子被鸟吃》,再加上数学老师发难,于是被开除了。从此郑渊洁没有上过一天学。

列夫尔斯泰大贵族出身,2岁丧母,9岁丧父,16岁上大学,大学三年级自动退学回家进行改革。在青年时期不好好读书,考试不及格,留级。他赌博、借债、鬼混……

这个的例子太多了,我从另一个方面举几个体育运动相关的例子,可能年轻的朋友都不知道,可以问问你们的父母。

80年代,中国有一批非常优秀的体育运动员,比如:体操王子李宁,打破过世界跳高记录的朱建华,还有乒乓球世界冠军马文革,还有羽毛球世界冠军赵建华,记得有一年参加世界比赛,他们全输了,而输的还很惨。于是国内的一些媒体和民众开始骂他们,甚至说他们是民族的败类、耻辱,还有很多人找上门要教训他们……

如果我们把绩效分比做在学校里的考试分,那么你是否会和我一样认为,考试的成绩只能代表这个人对这些知识点的掌握或理解,而且仅仅在这个时间点,根本不代表这个人根本就不行,更不代表他一直不行。因为挂科太多被学??耐?,并不见得这些人在社会上就无活生活下去,反而,他们中的有些人可能会考试成绩好的人还活得好。不是么?这样的例子在我们身边还少吗?

所以,当我看到某HR说某老员工——“他今天要不自己离开,未来一年也一定会因为绩效问题而被公司开了的”,除了感到居然有人类可以预知他人未来的可笑之外,我感到是一种悲哀,一种管理体制上的悲哀,我感到了在这HR考评背后一股非常强的暗流和不可见的力量让她干出了这样一件匪夷所思的事。

好些公司还考评价值观,价值观无可厚非,我觉得一个企业的价值观是非常必要的,但是考核价值观是件非常危险的事情。这个世界上和传统势力唱反调的人实在是太多了,而被定性为价值观有问题被迫害的人也是多了去了。被批斗被侮辱被毒打的老舍;因为同性恋问题,被迫害而自杀的图灵;因为不同意教会观点被监禁8年都不愿意放弃自己的信仰最终被烧死的布鲁诺,…… 这样的事情已经够多了,新的时代里不应该再发生这样的事了,无论大小。

考核价值观最大的问题就是非常容易的上纲上线,也非常容易的被制造政治斗争,也非常容易的扼杀各种不同思想,老实说,这从很大程度上是一种洗脑的手段——通过对人制造一种紧张或恐惧而达到控制思想的目的。

 

对公司和管理者想说的话

下面我来谈谈绩效考核我的一些观点。在谈这个观点前,你可以移步看一下这篇新闻报道——《绩效主义毁了索尼》。而近年来,“放弃绩效考核”的斗争已经从科技企业中的Adobe、戴尔、微软、亚马逊,席卷到德勤、埃森哲、普华永道等咨询服务类企业。甚至通用电气(GE)——曾经的绩效管理的鼻祖,也宣布抛弃正式的年度绩效考核。在刚过去的2016年,腾讯的张小龙对微信事业群发出“警惕KPI”的呼声;李彦宏在内部信中将百度的掉队归咎于“从管理层到员工对短期KPI的追逐”;雷军干脆宣布小米“继续坚持‘去KPI’的战略,放下包袱,解掉绳索,开开心心地做事?!?;王石也在个人微博中感慨:“绩效主义像企业的脓包”。

绩效考核在本质上就是像学校教育以分数论英雄,而忽略员工的成长和素质教育是一个道理。当学生和老师只关注考试分数时,而只有考试分数来评价老师和学生的优良中差时,老师和学生就会开始使用一些非常形式的方式来达到这个目标,比如:死记硬被,记套路,题海战术…… 而学习的能力的考评彻底地沦为了一种形式主义。反而,分数考的越高,脑子越死。(注:美国现行教育是不允许通过学生考试成绩来评价老师的能力的)

近几年来,一些大公司开始使用 OKR – Objectives, Key Result ,但是在实践过程中,我发现好些公司用OKR,本质上还是KPI – Key Performance Indicator, 因为OKR里面有一个Key Result,用来衡量 Objectives 的结果指标。于是,使用者习惯性的设置上了KPI。我个人认为 OKR 有三个非常大的特性:0)由员工提出,1)以目标为导向。2)全员共享。

举个例子,OKR可能会是制定成下面这个样子的:

Objectives:增强用户体验,

Key Results:

1)用户操作步骤减少20%以上,

2)客服减少40%以上工单,

3)用户99.9%的系统操作的响应时间为100ms以下

然后,把这个目标分解给产品、用户体验、技术团队,形成子的Objectives并关连上相应的父级的Key Result,比如,产品部门定义的Objectives:1)优化注册流程,减少2个步骤,2)优化红包算法,让用户更容易理解,3)提高商品质量,减少用户投诉。后端技术团队定义的Objectives: 1)定义SLA以及相关监控指标,2)自动化运维,减少故障恢复时间,3)提高性能,吞吐量在xxxqps下的99.9%的响应时间为xxms ……

这个Objective会从公司最高层一直分解到一线员工,信息完全透明,每个人都可以看到所有人被分解到目标,每个人都知道自己在为什么样的目标而奋头,而每个人也可以质疑,改进,建议调整最高层的目标和方向。而不是领到的是被层层消化过的变味的二手,三手甚至四五手的信息。

而 KPI 最大的问题就是用 OKR 里的 Key Results 拿来当目标,从而导致员工只知道要做什么,不知道为什么,不知道为什么,不能理解目标,工作也就成了实实在在的应付!

松下公司早在1933年,就召集168名员工,把松下未来250年的远景规划目标公布于众,从1956年开始,就定期宣布并解读自身的“五年计划”,帮助每位员工的目光从眼前的短期利益移开,树立自己的理想和目标,也促进了松下的可持续性发展。

然而,今时不同往昔,随着产品周期的不断缩减、竞争对手的持续涌入、高新技术的频频迭代,企业的战略的变化与调整变得更加频繁,朝令夕改的经营策略已经成为兵家常态。 在这一过程中,有多少员工了解调整之后的战略呢?员工的绩效指标又根据战略调整多少次了呢?

KPI本身是一种被动的、后置的考察,在工作完成之后考察员工的行为是否符合标准。因此,员工对于公司的目标漠不关心,只关心自己的KPI,因为这才是自己的最大的利益,为了达到KPI,有的员工开始不思考,并使用一些简单粗暴的玩法,其实这样既害了公司,也害了自己。自己的成长和进步也因为强大的 KPI 而抛在了脑后。

当然,KPI 绩效考核一般来说,不一定会毁掉公司的,相反,对于喜欢使用蛮力的劳动密集型的公司来说,可能还有所帮助,然而,KPI毁掉的一定是团队的文化和团队的挑战精神,以及创新和对事业的热情,甚至会让其中的人失去应有的正常的判断力(分不清充分和必要条件,分不清很多事的因果关系)。

 

对职场人想说的话

那么,对于个人来说,如何面对公司给自己的绩效考核呢?如何面对他们的绩效考核呢?

还是用学??际苑质醋龆员?,如果说,用考试分数论英雄,一个人考高分就是绩效上的人才,考不及格的人就是人渣,这对吗?当然不是。也许仅于对于考试来说可以把人分成三六九等,但是对于整个人生来说,考试成绩和一个人在这个社会里的的成就并没有非常直接的因果关系。面对现实的社会,最终很多成绩好的人为成绩差的人工作的例子也有很多很多了。

我想说什么?我想说的是——用一颗平常心来面对公司给你打的分数,因为那并不代表你的整个人生。但是,你要用一颗非常严肃的心来面对自己的个人发展和成长,因为这才是真正需要认真对待的事。

换句话说,如果要给一个人打绩效分,那不是由一个公司在一个短期的时间时打出来,而是由这个人在一个长期的时间里所能达到的成就得出来的。

就像WhatsApp的联合创始人Brian Acton 在 2009年时面试Facebook时没有面试通过,然而在 5 年以后,他把自己创办的公司以190亿美元卖给了FaceBook。阿里巴巴的马云不也一样吗?找工作各种被拒,开办的第一个公司成绩也不好,20年前,一堆人都说马云这也不行那也不行,然而,后面呢?反过来说,也很多职业经理人在公司里绩效非常好,然后到了创业公司却搞得非常的糟糕,这又说明了什么呢?

这就像动物一样,有的动物适合在水里生活,有的动物适合在陆地上,鱼在陆地上是无法生存的,你让老虎去完成游泳的工作,你让鱼去完成鸟类的工作,你能考核到什么呢?我们每个人都有适合自己的环境,找到适合自己的环境才是最关键的!与其去关注别人对自己的评价,不如去寻找适合自己的环境。

所以,一个特定环境下的绩效考核并不代表什么,而那些妄图用绩效考核去否定一个人的做法,或多或少就是“法西斯”或“红卫兵”的玩法。

好了!让我们不要再说绩效考核了,让我们回到,真正让自己提高,让自己成长,让自己的强的话题上来吧。这里,我需要转引一篇文章《Do the Right Thing, Wait to get fired》,文中提到《 Team Geek》这本书中的一句话

做正确的事情,等着被开除。

谷歌新员工(我们称做“Nooglers”)经?;嵛饰沂侨绾稳米约鹤鍪抡饷锤咝У?。我半开玩笑的告诉他们这很简单:我选择做正确的事情,为谷歌,为世界,然后回到座位上,等着被开除。如果没有被开除,那我就是做了正确的事情——为所有人。如果被开除了,那选错了老板。总之,两方面,我都是赢。这是我的职业发展策略。

注明一下,“做正确的事,等着被开除”并不是一句鸡汤,而是让你变强大的话。因为强者自强,只有强者才能追求真理,而不是委曲求全。

嗯,考试分数不是关键,别人对你的评价也不是关键,自己有没有成长有没有提高有没有上一个台阶才是关键。KPI不是关键,OKR也不是关键,有没有在做正确的事,这才是关键!不是这样吗?

其它

我大学四年级时,觉得马上就要离开学校了,当时想干点以后再以没有机会干的事。想来想去,就是上学这么多年来,从来没有不及格过,于是我任性了一把,挂了一个科,去补考了一下。挂科的时候也收到一些同学的笑话,还有老师的批评,不过,这让我感觉我的学校经历更完整了。因为,这让我在22岁的时候,就经历并大概明白了一些人生的道理。

从98年工作到2013年来,就像一个好学生一样,我从来没有出现过任何的工作绩效问题,反正还经常在工作中成为标杠型的人,然并卵,只有自己成长才是最真实的感觉?!白稣返氖?,等着被开除”,这可能是我迄今为止在职场里做的最疯狂也是最正确的事了。因为,这让我有更多的经历,让我从正确的事中得到提高,也让我内心变得越来越强大,也让我找到了更具挑战的事,更让我对自己有更清楚的认识。

最后,我知道一定会有人来怼我,所以,最后我还想留段话,留给那些还是想通过绩效来否定人的人。

如果你对我的绩效或技术能力有怀疑,没问题,那么希望你能做到下述我已做到的事,再来喷我,谢谢!

在你40岁,在父亲病重,孩子上学问题、房贷并未还清、你是全家唯一收入来源之类的中年?;那榭鱿?,辞去你现在的工作,不加入任何一家公司,不用自己的任何一分钱积蓄,不要任何人的投资和帮助。只通过自己的技术能力,为别人解决相应的技术难题(不做任何无技术含量的外包项目),来生存养家,并除了能照顾好自己的家人没有降低自己的生活水平之外,还能再养活3个每人年薪36万元的工程师

请问这样的绩效能打个几分呢?呵呵。

当然,不管怎么说,我还有很多路要走,还有很多不足,我还要继续努力。所以,我挑了一条对我来说最难走的路,作死创业……

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/17972.html/feed 71
Go语言的修饰器编程 http://www.chinamxjy.com/articles/17929.html http://www.chinamxjy.com/articles/17929.html#comments Thu, 01 Jun 2017 08:48:15 +0000 http://www.chinamxjy.com/?p=17929 Read More Read More

]]>
之前写过一篇《Python修饰器的函数式编程》,这种模式很容易的可以把一些函数装配到另外一些函数上,可以让你的代码更为的简单,也可以让一些“小功能型”的代码复用性更高,让代码中的函数可以像乐高玩具那样自由地拼装。所以,一直以来,我对修饰器decoration这种编程模式情有独钟,这里写一篇Go语言相关的文章。

看过Python修饰器那篇文章的同学,一定知道这是一种函数式编程的玩法——用一个高阶函数来包装一下。多唠叨一句,关于函数式编程,可以参看我之前写过一篇文章《函数式编程》,这篇文章主要是,想通过从过程式编程的思维方式过渡到函数式编程的思维方式,从而带动更多的人玩函数式编程,所以,如果你想了解一下函数式编程,那么可以移步先阅读一下。所以,Go语言的修饰器编程模式,其实也就是函数式编程的模式。

不过,要提醒注意的是,Go 语言的“糖”不多,而且又是强类型的静态无虚拟机的语言,所以,无法做到像 Java 和 Python 那样的优雅的修饰器的代码。当然,也许是我才才疏学浅,如果你知道有更多的写法,请你一定告诉我。先谢过了。

简单示例

我们先来看一个示例:

package main

import "fmt"

func decorator(f func(s string)) func(s string) {

        return func(s string) {
                fmt.Println("Started")
                f(s)
                fmt.Println("Done")
        }
}

func Hello(s string) {
        fmt.Println(s)
}

func main() {
        decorator(Hello)("Hello, World!")
}

我们可以看到,我们动用了一个高阶函数 decorator(),在调用的时候,先把 Hello() 函数传进去,然后其返回一个匿名函数,这个匿名函数中除了运行了自己的代码,也调用了被传入的 Hello() 函数。

这个玩法和 Python 的异曲同工,只不过,有些遗憾的是,Go 并不支持像 Python 那样的 @decorator 语法糖。所以,在调用上有些难看。当然,如果你要想让代码容易读一些,你可以这样:

hello := decorator(Hello)
hello("Hello")

我们再来看一个和计算运行时间的例子:

package main

import (
  "fmt"
  "reflect"
  "runtime"
  "time"
)

type SumFunc func(int64, int64) int64

func getFunctionName(i interface{}) string {
  return runtime.FuncForPC(reflect.ValueOf(i).Pointer()).Name()
}

func timedSumFunc(f SumFunc) SumFunc {
  return func(start, end int64) int64 {

    defer func(t time.Time) {
      fmt.Printf("--- Time Elapsed (%s): %v ---\n", 
          getFunctionName(f), time.Since(t))
    }(time.Now())

    return f(start, end)
  }
}

func Sum1(start, end int64) int64 {
  var sum int64
  sum = 0
  if start > end {
    start, end = end, start
  }
  for i := start; i <= end; i++ {
    sum += i
  }
  return sum
}

func Sum2(start, end int64) int64 {
  if start > end {
    start, end = end, start
  }
  return (end - start + 1) * (end + start) / 2
}

func main() {

  sum1 := timedSumFunc(Sum1)
  sum2 := timedSumFunc(Sum2)

  fmt.Printf("%d, %d\n", sum1(-10000, 10000000), sum2(-10000, 10000000))
}

关于上面的代码,有几个事说明一下:

1)有两个 Sum 函数,Sum1() 函数就是简单的做个循环,Sum2() 函数动用了数据公式。(注意:start 和 end 有可能有负数的情况)

2)代码中使用了 Go 语言的反射机器来获取函数名。

3)修饰器函数是 timedSumFunc()

运行后输出:

$ go run time.sum.go
--- Time Elapsed (main.Sum1): 3.557469ms ---
--- Time Elapsed (main.Sum2): 291ns ---
49999954995000, 49999954995000

HTTP 相关的一个示例

我们再来看一个处理 HTTP 请求的相关的例子。

先看一个简单的 HTTP Server 的代码。

package main

import (
        "fmt"
        "log"
        "net/http"
        "strings"
)

func WithServerHeader(h http.HandlerFunc) http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
                log.Println("--->WithServerHeader()")
                w.Header().Set("Server", "HelloServer v0.0.1")
                h(w, r)
        }
}

func hello(w http.ResponseWriter, r *http.Request) {
        log.Printf("Recieved Request %s from %s\n", r.URL.Path, r.RemoteAddr)
        fmt.Fprintf(w, "Hello, World! "+r.URL.Path)
}

func main() {
        http.HandleFunc("/v1/hello", WithServerHeader(hello))
        err := http.ListenAndServe(":8080", nil)
        if err != nil {
                log.Fatal("ListenAndServe: ", err)
        }
}

上面代码中使用到了修饰模式,WithServerHeader() 函数就是一个 Decorator,其传入一个 http.HandlerFunc,然后返回一个改写的版本。上面的例子还是比较简单,用 WithServerHeader() 就可以加入一个 Response 的 Header。

于是,这样的函数我们可以写出好些个。如下所示,有写 HTTP 响应头的,有写认证 Cookie 的,有检查认证Cookie的,有打日志的……

package main

import (
        "fmt"
        "log"
        "net/http"
        "strings"
)

func WithServerHeader(h http.HandlerFunc) http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
                log.Println("--->WithServerHeader()")
                w.Header().Set("Server", "HelloServer v0.0.1")
                h(w, r)
        }
}

func WithAuthCookie(h http.HandlerFunc) http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
                log.Println("--->WithAuthCookie()")
                cookie := &http.Cookie{Name: "Auth", Value: "Pass", Path: "/"}
                http.SetCookie(w, cookie)
                h(w, r)
        }
}

func WithBasicAuth(h http.HandlerFunc) http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
                log.Println("--->WithBasicAuth()")
                cookie, err := r.Cookie("Auth")
                if err != nil || cookie.Value != "Pass" {
                        w.WriteHeader(http.StatusForbidden)
                        return
                }
                h(w, r)
        }
}

func WithDebugLog(h http.HandlerFunc) http.HandlerFunc {
        return func(w http.ResponseWriter, r *http.Request) {
                log.Println("--->WithDebugLog")
                r.ParseForm()
                log.Println(r.Form)
                log.Println("path", r.URL.Path)
                log.Println("scheme", r.URL.Scheme)
                log.Println(r.Form["url_long"])
                for k, v := range r.Form {
                        log.Println("key:", k)
                        log.Println("val:", strings.Join(v, ""))
                }
                h(w, r)
        }
}
func hello(w http.ResponseWriter, r *http.Request) {
        log.Printf("Recieved Request %s from %s\n", r.URL.Path, r.RemoteAddr)
        fmt.Fprintf(w, "Hello, World! "+r.URL.Path)
}

func main() {
        http.HandleFunc("/v1/hello", WithServerHeader(WithAuthCookie(hello)))
        http.HandleFunc("/v2/hello", WithServerHeader(WithBasicAuth(hello)))
        http.HandleFunc("/v3/hello", WithServerHeader(WithBasicAuth(WithDebugLog(hello))))
        err := http.ListenAndServe(":8080", nil)
        if err != nil {
                log.Fatal("ListenAndServe: ", err)
        }
}

多个修饰器的 Pipeline

在使用上,需要对函数一层层的套起来,看上去好像不是很好看,如果需要 decorator 比较多的话,代码会比较难看了。嗯,我们可以重构一下。

重构时,我们需要先写一个工具函数——用来遍历并调用各个 decorator:

type HttpHandlerDecorator func(http.HandlerFunc) http.HandlerFunc

func Handler(h http.HandlerFunc, decors ...HttpHandlerDecorator) http.HandlerFunc {
        for i := range decors {
                d := decors[len(decors)-1-i] // iterate in reverse
                h = d(h)
        }
        return h
}

然后,我们就可以像下面这样使用了。

http.HandleFunc("/v4/hello", Handler(hello,
                WithServerHeader, WithBasicAuth, WithDebugLog))

这样的代码是不是更易读了一些?pipeline 的功能也就出来了。

泛型的修饰器

不过,对于 Go 的修饰器模式,还有一个小问题 —— 好像无法做到泛型,就像上面那个计算时间的函数一样,其代码耦合了需要被修饰的函数的接口类型,无法做到非常通用,如果这个事解决不了,那么,这个修饰器模式还是有点不好用的。

因为 Go 语言不像 Python 和 Java,Python是动态语言,而 Java 有语言虚拟机,所以他们可以干好些比较变态的事,然而 Go 语言是一个静态的语言,这意味着其类型需要在编译时就要搞定,否则无法编译。不过,Go 语言支持的最大的泛型是 interface{} 还有比较简单的 reflection 机制,在上面做做文章,应该还是可以搞定的。

废话不说,下面是我用 reflection 机制写的一个比较通用的修饰器(为了便于阅读,我删除了出错判断代码)

func Decorator(decoPtr, fn interface{}) (err error) {
        var decoratedFunc, targetFunc reflect.Value

        decoratedFunc = reflect.ValueOf(decoPtr).Elem()
        targetFunc = reflect.ValueOf(fn)

        v := reflect.MakeFunc(targetFunc.Type(),
                func(in []reflect.Value) (out []reflect.Value) {
                        fmt.Println("before")
                        out = targetFunc.Call(in)
                        fmt.Println("after")
                        return
                })

        decoratedFunc.Set(v)
        return
}

上面的代码动用了 reflect.MakeFunc() 函数制出了一个新的函数其中的 targetFunc.Call(in) 调用了被修饰的函数。关于 Go 语言的反射机制,推荐官方文章 —— 《The Laws of Reflection》,在这里我不多说了。

上面这个 Decorator() 需要两个参数,

  • 第一个是出参 decoPtr ,就是完成修饰后的函数
  • 第二个是入参 fn ,就是需要修饰的函数

这样写是不是有些二?的确是的。不过,这是我个人在 Go 语言里所能写出来的最好的的代码了。如果你知道更多优雅的,请你一定告诉我!

好的,让我们来看一下使用效果。首先假设我们有两个需要修饰的函数:

func foo(a, b, c int) int {
        fmt.Printf("%d, %d, %d \n", a, b, c)
        return a + b + c
}

func bar(a, b string) string {
        fmt.Printf("%s, %s \n", a, b)
        return a + b
}

然后,我们可以这样做:

type MyFoo func(int, int, int) int
var myfoo MyFoo
Decorator(&myfoo, foo)
myfoo(1, 2, 3)

你会发现,使用 Decorator() 时,还需要先声明一个函数签名,感觉好傻啊。一点都不泛型,不是吗?

嗯。如果你不想声明函数签名,那么你也可以这样

mybar := bar
Decorator(&mybar, bar)
mybar("hello,", "world!")

好吧,看上去不是那么的漂亮,但是 it works??囱?Go 语言目前本身的特性无法做成像 Java 或 Python 那样,对此,我们只能多求 Go 语言多放糖了!

Again, 如果你有更好的写法,请你一定要告诉我。

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/17929.html/feed 17
如何重构“箭头型”代码 http://www.chinamxjy.com/articles/17757.html http://www.chinamxjy.com/articles/17757.html#comments Wed, 05 Apr 2017 10:07:14 +0000 http://www.chinamxjy.com/?p=17757 Read More Read More

]]>
本文主要起因是,一次在微博上和朋友关于嵌套好几层的if-else语句的代码重构的讨论(微博原文),在微博上大家有各式各样的问题和想法。按道理来说这些都是编程的基本功,似乎不太值得写一篇文章,不过我觉得很多东西可以从一个简单的东西出发,到达本质,所以,我觉得有必要在这里写一篇的文章。不一定全对,只希望得到更多的讨论,因为有了更深入的讨论才能进步。

文章有点长,我在文章最后会给出相关的思考和总结陈词,你可以跳到结尾。

所谓箭头型代码,基本上来说就是下面这个图片所示的情况。

那么,这样“箭头型”的代码有什么问题呢?看上去也挺好看的,有对称美。但是……

关于箭头型代码的问题有如下几个:

1)我的显示器不够宽,箭头型代码缩进太狠了,需要我来回拉水平滚动条,这让我在读代码的时候,相当的不舒服。

2)除了宽度外还有长度,有的代码的if-else里的if-else里的if-else的代码太多,读到中间你都不知道中间的代码是经过了什么样的层层检查才来到这里的。

总而言之,“箭头型代码”如果嵌套太多,代码太长的话,会相当容易让维护代码的人(包括自己)迷失在代码中,因为看到最内层的代码时,你已经不知道前面的那一层一层的条件判断是什么样的,代码是怎么运行到这里的,所以,箭头型代码是非常难以维护和Debug的。

微博上的案例 与 Guard Clauses

OK,我们先来看一下微博上的那个示例,代码量如果再大一点,嵌套再多一点,你很容易会在条件中迷失掉(下面这个示例只是那个“大箭头”下的一个小箭头)

FOREACH(Ptr<WfExpression>, argument, node->arguments) {
    int index = manager->expressionResolvings.Keys().IndexOf(argument.Obj());
    if (index != -1) {
        auto type = manager->expressionResolvings.Values()[index].type;
        if (! types.Contains(type.Obj())) {
            types.Add(type.Obj());
            if (auto group = type->GetTypeDescriptor()->GetMethodGroupByName(L"CastResult", true)) {
                int count = group->GetMethodCount();
                for (int i = 0; i < count; i++) { auto method = group->GetMethod(i);
                    if (method->IsStatic()) {
                        if (method->GetParameterCount() == 1 &&
                            method->GetParameter(0)->GetType()->GetTypeDescriptor() == description::GetTypeDescriptor<DescriptableObject>() &&
                            method->GetReturn()->GetTypeDescriptor() != description::GetTypeDescriptor<void>() ) {
                            symbol->typeInfo = CopyTypeInfo(method->GetReturn());
                            break;
                        }
                    }
                }
            }
        }
    }
}

上面这段代码,可以把条件反过来写,然后就可以把箭头型的代码解掉了,重构的代码如下所示:

FOREACH(Ptr<WfExpression>, argument, node->arguments) {
    int index = manager->expressionResolvings.Keys().IndexOf(argument.Obj());
    if (index == -1)  continue;
    
    auto type = manager->expressionResolvings.Values()[index].type;
    if ( types.Contains(type.Obj()))  continue;
    
    types.Add(type.Obj());

    auto group = type->GetTypeDescriptor()->GetMethodGroupByName(L"CastResult", true);
    if  ( ! group ) continue;
 
    int count = group->GetMethodCount();
    for (int i = 0; i < count; i++) { auto method = group->GetMethod(i);
        if (! method->IsStatic()) continue;
       
        if ( method->GetParameterCount() == 1 &&
               method->GetParameter(0)->GetType()->GetTypeDescriptor() == description::GetTypeDescriptor<DescriptableObject>() &&
               method->GetReturn()->GetTypeDescriptor() != description::GetTypeDescriptor<void>() ) {
            symbol->typeInfo = CopyTypeInfo(method->GetReturn());
            break;
        }
    }
}

这种代码的重构方式叫 Guard Clauses

这里的思路其实就是,让出错的代码先返回,前面把所有的错误判断全判断掉,然后就剩下的就是正常的代码了。

抽取成函数

微博上有些人说,continue 语句破坏了阅读代码的通畅,我觉得他们一定没有好好读这里面的代码,其实,我们可以看到,所有的 if 语句都是在判断是否出错的情况,所以,在维护代码的时候,你可以完全不理会这些 if 语句,因为都是出错处理的,而剩下的代码都是正常的功能代码,反而更容易阅读了。当然,一定有不是上面代码里的这种情况,那么,不用continue ,我们还能不能重构呢?

当然可以,抽成函数:

bool CopyMethodTypeInfo(auto &method, auto &group, auto &symbol) 
{
    if (! method->IsStatic()) {
        return true;
    }
    if ( method->GetParameterCount() == 1 &&
           method->GetParameter(0)->GetType()->GetTypeDescriptor() == description::GetTypeDescriptor<DescriptableObject>() &&
           method->GetReturn()->GetTypeDescriptor() != description::GetTypeDescriptor<void>() ) {
        symbol->typeInfo = CopyTypeInfo(method->GetReturn());
        return false;
    }
    return true;
}

void ExpressionResolvings(auto &manager, auto &argument, auto &symbol) 
{
    int index = manager->expressionResolvings.Keys().IndexOf(argument.Obj());
    if (index == -1) return;
    
    auto type = manager->expressionResolvings.Values()[index].type;
    if ( types.Contains(type.Obj())) return;

    types.Add(type.Obj());
    auto group = type->GetTypeDescriptor()->GetMethodGroupByName(L"CastResult", true);
    if  ( ! group ) return;

    int count = group->GetMethodCount();
    for (int i = 0; i < count; i++) { auto method = group->GetMethod(i);
        if ( ! CopyMethodTypeInfo(method, group, symbol) ) break;
    }
}

...
...
FOREACH(Ptr<WfExpression>, argument, node->arguments) {
    ExpressionResolvings(manager, arguments, symbol)
}
...
...

你发出现,抽成函数后,代码比之前变得更容易读和更容易维护了。不是吗?

有人说:“如果代码不共享,就不要抽取成函数!”,持有这个观点的人太死读书了。函数是代码的封装或是抽象,并不一定用来作代码共享使用,函数用于屏蔽细节,让其它代码耦合于接口而不是细节实现,这会让我们的代码更为简单,简单的东西都能让人易读也易维护。这才是函数的作用。

嵌套的 if 外的代码

微博上还有人问,原来的代码如果在各个 if 语句后还有要执行的代码,那么应该如何重构。比如下面这样的代码。

for(....) {
    do_before_cond1()
    if (cond1) {
        do_before_cond2();
        if (cond2) {
            do_before_cond3();
            if (cond3) {
                do_something();
            }
            do_after_cond3();
        }
        do_after_cond2();
    }
    do_after_cond1();
}

上面这段代码中的那些 do_after_condX() 是无论条件成功与否都要执行的。所以,我们拉平后的代码如下所示:

for(....) {
    do_before_cond1();
    if ( !cond1 ) {
        do_after_cond1();
        continue
    } 
    do_after_cond1();

    do_before_cond2();
    if ( !cond2 ) { 
        do_after_cond2();
        continue;
    }
    do_after_cond2();

    do_before_cond3();
    if ( !cond3 ) {
        do_after_cond3();
        continue;
    }
    do_after_cond3();

    do_something();  
}

你会发现,上面的 do_after_condX 出现了两份。如果 if 语句块中的代码改变了某些do_after_condX依赖的状态,那么这是最终版本。

但是,如果它们之前没有依赖关系的话,根据 DRY 原则,我们就可以只保留一份,那么直接掉到 if 条件前就好了,如下所示:

for(....) {
    do_before_cond1();
    do_after_cond1();
    if ( !cond1 ) continue;
 
    do_before_cond2();
    do_after_cond2();
    if ( !cond2 ) continue;

    do_before_cond3();
    do_after_cond3();
    if ( !cond3 ) continue;

    do_something();  
}

此时,你会说,我靠,居然,改变了执行的顺序,把条件放到 do_after_condX() 后面去了。这会不会有问题???

其实,你再分析一下之前的代码,你会发现,本来,cond1 是判断 do_before_cond1() 是否出错的,如果有成功了,才会往下执行。而 do_after_cond1() 是无论如何都要执行的。从逻辑上来说,do_after_cond1()其实和do_before_cond1()的执行结果无关,而 cond1 却和是否去执行 do_before_cond2() 相关了。如果我把断行变成下面这样,反而代码逻辑更清楚了。

for(....) {

    do_before_cond1();
    do_after_cond1();


    if ( !cond1 ) continue;  // <-- cond1 成了是否做第二个语句块的条件
    do_before_cond2();
    do_after_cond2();

    if ( !cond2 ) continue; // <-- cond2 成了是否做第三个语句块的条件
    do_before_cond3();
    do_after_cond3();

    if ( !cond3 ) continue; //<-- cond3 成了是否做第四个语句块的条件
    do_something(); 
 
}

于是乎,在未来维护代码的时候,维护人一眼看上去就明白,代码在什么时候会执行到哪里。 这个时候,你会发现,把这些语句块抽成函数,代码会干净的更多,再重构一版:

bool do_func3() {
   do_before_cond2();
   do_after_cond2();
   return cond3;
}

bool do_func2() {
   do_before_cond2();
   do_after_cond2();
   return cond2;
}

bool do_func1() {
   do_before_cond1();
   do_after_cond1();
   return cond1;
}

// for-loop 你可以重构成这样
for (...) {
    bool cond = do_func1();
    if (cond) cond = do_func2();
    if (cond) cond = do_func3();
    if (cond) do_something();
}

// for-loop 也可以重构成这样
for (...) {
    if ( ! do_func1() ) continue;
    if ( ! do_func2() ) continue;
    if ( ! do_func3() ) continue;
    do_something();
}

上面,我给出了两个版本的for-loop,你喜欢哪个?我喜欢第二个。这个时候,因为for-loop里的代码非常简单,就算你不喜欢 continue ,这样的代码阅读成本已经很低了。

状态检查嵌套

接下来,我们再来看另一个示例。下面的代码的伪造了一个场景——把两个人拉到一个一对一的聊天室中,因为要检查双方的状态,所以,代码可能会写成了“箭头型”。

int ConnectPeer2Peer(Conn *pA, Conn* pB, Manager *manager)
{
    if ( pA->isConnected() ) {
        manager->Prepare(pA);
        if ( pB->isConnected() ) {
            manager->Prepare(pB);
            if ( manager->ConnectTogther(pA, pB) ) {
                pA->Write("connected");
                pB->Write("connected");
                return S_OK;
            }else{
                return S_ERROR;
            }

        }else {
            pA->Write("Peer is not Ready, waiting...");
            return S_RETRY;
        }
    }else{
        if ( pB->isConnected() ) {
            manager->Prepare();
            pB->Write("Peer is not Ready, waiting...");
            return S_RETRY;
        }else{
            pA->Close();
            pB->Close();
            return S_ERROR;
        }
    }
    //Shouldn't be here!
    return S_ERROR;
}

重构上面的代码,我们可以先分析一下上面的代码,说明了,上面的代码就是对 PeerA 和 PeerB 的两个状态 “连上”, “未连上” 做组合 “状态” (注:实际中的状态应该比这个还要复杂,可能还会有“断开”、“错误”……等等状态), 于是,我们可以把代码写成下面这样,合并上面的嵌套条件,对于每一种组合都做出判断。这样一来,逻辑就会非常的干净和清楚。

int ConnectPeer2Peer(Conn *pA, Conn* pB, Manager *manager)
{
    if ( pA->isConnected() ) {
        manager->Prepare(pA);
    }

    if ( pB->isConnected() ) {
        manager->Prepare(pB);
    }

    // pA = YES && pB = NO
    if (pA->isConnected() && ! pB->isConnected()  ) {
        pA->Write("Peer is not Ready, waiting");
        return S_RETRY;
    // pA = NO && pB = YES
    }else if ( !pA->isConnected() && pB->isConnected() ) {
        pB->Write("Peer is not Ready, waiting");
        return S_RETRY;
    // pA = YES && pB = YES
    }else if (pA->isConnected() && pB->isConnected()  ) {
        if ( ! manager->ConnectTogther(pA, pB) ) {
            return S_ERROR;
        }
        pA->Write("connected");
        pB->Write("connected");
        return S_OK;
    }

    // pA = NO, pB = NO
    pA->Close();
    pB->Close();
    return S_ERROR;
}

延伸思考

对于 if-else 语句来说,一般来说,就是检查两件事:错误状态。

检查错误

对于检查错误来说,使用 Guard Clauses 会是一种标准解,但我们还需要注意下面几件事:

1)当然,出现错误的时候,还会出现需要释放资源的情况。你可以使用 goto fail; 这样的方式,但是最优雅的方式应该是C++面向对象式的 RAII 方式。

2)以错误码返回是一种比较简单的方式,这种方式有很一些问题,比如,如果错误码太多,判断出错的代码会非常复杂,另外,正常的代码和错误的代码会混在一起,影响可读性。所以,在更为高组的语言中,使用 try-catch 异常捕捉的方式,会让代码更为易读一些。

检查状态

对于检查状态来说,实际中一定有更为复杂的情况,比如下面几种情况:

1)像TCP协议中的两端的状态变化。

2)像shell各个命令的命令选项的各种组合。

3)像游戏中的状态变化(一棵非常复杂的状态树)。

4)像语法分析那样的状态变化。

对于这些复杂的状态变化,其本上来说,你需要先定义一个状态机,或是一个子状态的组合状态的查询表,或是一个状态查询分析树。

写代码时,代码的运行中的控制状态或业务状态是会让你的代码流程变得混乱的一个重要原因,重构“箭头型”代码的一个很重要的工作就是重新梳理和描述这些状态的变迁关系。

总结

好了,下面总结一下,把“箭头型”代码重构掉的几个手段如下:

1)使用 Guard Clauses 。 尽可能的让出错的先返回, 这样后面就会得到干净的代码。

2)把条件中的语句块抽取成函数。 有人说:“如果代码不共享,就不要抽取成函数!”,持有这个观点的人太死读书了。函数是代码的封装或是抽象,并不一定用来作代码共享使用,函数用于屏蔽细节,让其它代码耦合于接口而不是细节实现,这会让我们的代码更为简单,简单的东西都能让人易读也易维护,写出让人易读易维护的代码才是重构代码的初衷!

3)对于出错处理,使用try-catch异常处理和RAII机制。返回码的出错处理有很多问题,比如:A) 返回码可以被忽略,B) 出错处理的代码和正常处理的代码混在一起,C) 造成函数接口污染,比如像atoi()这种错误码和返回值共用的糟糕的函数。

4)对于多个状态的判断和组合,如果复杂了,可以使用“组合状态表”,或是状态机加Observer的状态订阅的设计模式。这样的代码即解了耦,也干净简单,同样有很强的扩展性。

5) 重构“箭头型”代码其实是在帮你重新梳理所有的代码和逻辑,这个过程非常值得为之付出。重新整思路去想尽一切办法简化代码的过程本身就可以让人成长。

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/17757.html/feed 43
AWS 的 S3 故障回顾和思考 http://www.chinamxjy.com/articles/17737.html http://www.chinamxjy.com/articles/17737.html#comments Fri, 03 Mar 2017 06:20:03 +0000 http://www.chinamxjy.com/?p=17737 Read More Read More

]]>
Gitlab的误删除数据事件没几天,“不沉航母” AWS S3 (Simple Storage Service)几天前也“沉”了4个小时,墙外的半个互联网也跟着挂了。如约,按 AWS 惯例,AWS今天给出了一个简单的故障报告《Summary of the Amazon S3 Service Disruption in the Northern Virginia (US-EAST-1) Region》。这个故障和简单来说和Gitlab一样,也是人员误操作。先简单的说一下这份报中说了什么。

故障原因

简单来说,这天,有一个 AWS 工程师在调查?Northern Virginia (US-EAST-1) Region 上 S3 的一个和账务系统相关的问题,这个问题是S3的账务系统变慢了(我估计这个故障在Amazon里可能是Sev2级,Sev2级的故障在Amazon算是比较大的故障,需要很快解决),Oncall的开发工程师(注:Amazon的运维都是由开发工程师来干的,所以Amazon内部嬉称SDE-Software Developer Engineer 为 Someone Do Everything)想移除一个账务系统里的一个子系统下的一些少量的服务器(估计这些服务器上有问题,所以想移掉后重新部署),结果呢,有一条命令搞错了,导致了移除了大量的S3的控制系统。包括两个很重要的子系统:

1)一个是S3的对象索引服务(Index),其中存储了S3对象的metadata和位置信息。这个服务也提供了所有的 GET,LIST,PUT 和DELETE请求。

2)一个是S3的位置服务系统(Placement),这个服务提供对象的存储位置和索引服务的系统。这个系统主要是用于处理PUT新对象请求。

这就是为什么S3不可访问的原因。

在后面,AWS也说明了一下故障恢复的过程,其中重点提到了这点——

虽然整个S3的是做过充分的故障设计的(注:AWS的七大Design Principle 之一 Design for Failure)—— 就算是最核心的组件或服务出问题了,系统也能恢复。但是,可能是在过去的日子里 S3 太稳定了,所以,AWS 在很长很长一段时间内都没有重启过 S3 的核心服务,而过去这几年,S3 的数据对象存储级数级的成长(S3存了什么样数量级的对象,因为在Amazon工作过,所以多大概知道是个什么数量级,这里不能说,不过,老实说,很惊人的),所以,这两个核心服务在启动时要重建并校验对象索引元数据的完整性,这个过程没想到花了这么长的时候。而Placement服务系统依赖于Index 服务,所以花了更长的时间。

了解过系统底层的技术人员应该都知道这两个服务有多重要,简而言之,这两个系统就像是Unix/Linux文件系统中的inode,或是像HDFS里的node name,如果这些元数据丢失,那么,用户的所有数据基本上来说就等于全丢了。

而要恢复索引系统,就像你的操作系统从异常关机后启动,文件系统要做系统自检那样,硬盘越大,文件越多,这个过程就越慢。

另外,这次,AWS没有使用像以前那样 Outage 的故障名称,用的是 “Increased Error Rate” 这样的东西。我估计是没有把所有这两个服务删除完,估计有些用户是可以用的,有的用户是则不行了。

后续改进

在这篇故障简报中,AWS 也提到了下面的这些改进措施——

1)改进运维操作工具。对于此次故障的运维工具,有下面改进:

  • 让删除服务这个操作变慢一些(陈皓注:这样错了也可以有时间反悔,相对于一个大规模的分布式系统,这招还是很不错的,至少在系统报警时有也可以挽救)
  • 加上一个最小资源数限制的SafeGuard(陈皓注:就是说,任何服务在运行时都应该有一个最小资源数,分布式集群控制系统会强行维护服务正常运行的最小的一个资源数)
  • 举一反三,Review所有和其它的运维工具,保证他们也相关的检查。

2)改进恢复过程。对于恢复时间过长的问题,有如下改进:

  • 分解现有厚重的重要服务成更小的单元(在 AWS,Service是大服务,小服务被称之为 Cell),AWS 会把这几个重要的服务重构成 Cell服务。(陈皓注:这应该就是所谓的“微服务”了吧)。这样,服务粒度变小,重启也会快一些,而且还可以减少故障面(原文:blast radius – 爆炸半径)
  • 今年内完成对 Index 索引服务的分区计划。

 

相关思考

下面是我对这一故障的相关思考——

0)太喜欢像Gitlab和AWS这样的故障公开了,那怕是一个自己人为的低级错误。不掩盖,不文过饰非,透明且诚恳。Cool!

1)这次事件,还好没有丢失这么重要的数据,不然的话,将是灾难性的。

2)另外,面对在 US-EASE-1 这个老牌 Region 上的海量的对象,而且能在几个小时内恢复,很不容易了。

3)这个事件,再次映证了我在《关于高可用的系统》中提到的观点:一个系统的高可用的因素很多,不仅仅只是系统架构,更重要的是——高可用运维。

4)对于高可用的运维,平时的故障演习是很重要的。AWS 平时应该没有相应的故障演习,所以导致要么长期不出故障,一出就出个大的让你措手不及。这点,Facebook就好一些,他们每个季度扔个骰子,随机关掉一个IDC一天。Netflix 也有相关的 Chaos Monkey,我以前在的路透每年也会做一次大规模的故障演练——灾难演习。

5)AWS对于后续的改进可以看出他的技术范儿??梢钥吹狡涓慕桨甘怯眉际跞米约旱南低掣母呖捎?。然后,对比国内的公司对于这样的故障,基本上会是下面这样的画风:

a)加上更多更为严格的变更和审批流程,

b)使用限制更多的权限系统和审批系统

c)使用更多的人来干活(一个人干事,另一个人在旁边看)

d)使用更为厚重的测试和发布过程

e)惩罚故障人,用价值观教育工程师。

这还是我老生长谈的那句话——如果你是一个技术公司,你就会更多的相信技术而不是管理。相信技术会用技术来解决问题,相信管理,那就只会有制度、流程和价值观来解决问题。(注意:这里我并没有隔离技术和管理,只是更为倾向于用技术解决问题)

最后,你是要建一个 “高可用的技术系统” ,还是一个 “高用的管理系统”? ;-)

(全文完)

 


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/17737.html/feed 53
从Gitlab误删除数据库想到的 http://www.chinamxjy.com/articles/17680.html http://www.chinamxjy.com/articles/17680.html#comments Thu, 02 Feb 2017 08:11:28 +0000 http://www.chinamxjy.com/?p=17680 Read More Read More

]]>
昨天,Gitlab.com发生了一个大事,某同学误删了数据库,这个事看似是个低级错误,不过,因为Gitlab把整个过程的细节都全部暴露出来了,所以,可以看到很多东西,而对于类似这样的事情,我自己以前也干过,而在最近的两公司中我也见过(Amazon中见过一次,阿里中见过至少四次),正好通过这个事来说说一下自己的一些感想和观点吧。我先放个观点:你觉得有备份系统就不会丢数据了吗?

事件回顾

整个事件的回顾Gitlab.com在第一时间就放到了Google Doc上,事后,又发了一篇Blog来说明这个事,在这里,我简单的回顾一下这个事件的过程。

首先,一个叫YP的同学在给gitlab的线上数据库做一些负载均衡的工作,在做这个工作时的时候突发了一个情况,Gitlab被DDoS攻击,数据库的使用飙高,在block完攻击者的IP后,发现有个staging的数据库(db2.staging)已经落后生产库4GB的数据,于是YP同学在Fix这个staging库的同步问题的时候,发现db2.staging有各种问题都和主库无法同步,在这个时候,YP同学已经工作的很晚了,在尝试过多个方法后,发现db2.staging都hang在那里,无法同步,于是他想把db2.staging的数据库删除了,这样全新启动一个新的复制,结果呢,删除数据库的命令错误的敲在了生产环境上(db1.cluster),结果导致整个生产数据库被误删除。(陈皓注:这个失败基本上就是 “工作时间过长” + “在多数终端窗口中切换中迷失掉了”

在恢复的过程中,他们发现只有db1.staging的数据库可以用于恢复,而其它的5种备份机制都不可用,第一个是数据库的同步,没有同步webhook,第二个是对硬盘的快照,没有对数据库做,第三个是用pg_dump的备份,发现版本不对(用9.2的版本去dump 9.6的数据)导致没有dump出数据,第四个S3的备份,完全没有备份上,第五个是相关的备份流程是问题百出的,只有几个粗糙的人肉的脚本和糟糕的文档,也就是说,不但是是人肉的,而且还是完全不可执行的。(陈皓注:就算是这些备份机制都work,其实也有问题,因为这些备份大多数基本上都是24小时干一次,所以,要从这些备份恢复也一定是是要丢数据的了,只有第一个数据库同步才会实时一些

最终,gitlab从db1.staging上把6个小时前的数据copy回来,结果发现速度非常的慢,备份结点只有60Mbits/S,拷了很长时间(陈皓注:为什么不把db1.staging给直接变成生产机?因为那台机器的性能很差)。数据现在的恢复了,不过,因为恢复的数据是6小时前的,所以,有如下的数据丢失掉了:

  • 粗略估计,有4613 的项目, 74 forks, ?和 350 imports 丢失了;但是,因为Git仓库还在,所以,可以从Git仓库反向推导数据库中的数据,但是,项目中的issues等就完全丢失了。
  • 大约有±4979 提交记录丢失了(陈皓注:估计也可以用git仓库中反向恢复)。
  • 可能有 707 ?用户丢失了,这个数据来自Kibana的日志。
  • 在1月31日17:20 后的Webhooks 丢失了。

因为Gitlab把整个事件的细节公开了出来,所以,也得到了很多外部的帮助,2nd Quadrant的CTO –?Simon Riggs?在他的blog上也发布文章 Dataloss at Gitlab 给了一些非常不错的建议:

  • 关于PostgreSQL 9.6的数据同步hang住的问题,可能有一些Bug,正在fix中。
  • PostgreSQL有4GB的同步滞后是正常的,这不是什么问题。
  • 正常的停止从结点,会让主结点自动释放WALSender的链接数,所以,不应该重新配置主结点的 max_wal_senders 参数。但是,停止从结点时,主结点的复数连接数不会很快的被释放,而新启动的从结点又会消耗更多的链接数。他认为,Gitlab配置的32个链接数太高了,通常来说,2到4个就足够了。
  • 另外,之前gitlab配置的max_connections=8000太高了,现在降到2000个是合理的。
  • pg_basebackup 会先在主结点上建一个checkpoint,然后再开始同步,这个过程大约需要4分钟。
  • 手动的删除数据库目录是非常危险的操作,这个事应该交给程序来做。推荐使用刚release 的 repmgr
  • 恢复备份也是非常重要的,所以,也应该用相应的程序来做。推荐使用 barman?(其支持S3)
  • 测试备份和恢复是一个很重要的过程。

看这个样子,估计也有一定的原因是——Gitlab的同学对PostgreSQL不是很熟悉。

随后,Gitlab在其网站上也开了一系列的issues,其issues列表在这里 Write post-mortem?(这个列表可能还会在不断更新中)

从上面的这个列表中,我们可以看到一些改进措施了。挺好的,不过我觉得还不是很够。

相关的思考

因为类似这样的事,我以前也干过(误删除过数据库,在多个终端窗口中迷失掉了自己所操作的机器……),而且我在amazon里也见过一次,在阿里内至少见过四次以上(在阿里人肉运维的误操作的事故是我见过最多的),但是我无法在这里公开分享,私下可以分享。在这里,我只想从非技术和技术两个方面分享一下我的经验和认识。

技术方面

人肉运维

一直以来,我都觉得直接到生产线上敲命令是一种非常不好的习惯。我认为,一个公司的运维能力的强弱和你上线上环境敲命令是有关的,你越是喜欢上线敲命令你的运维能力就越弱,越是通过自动化来处理问题,你的运维能力就越强。理由如下:

其一,如果说对代码的改动都是一次发布的话,那么,对生产环境的任何改动(包括硬件、操作系统、网络、软件配置……),也都算是一次发布。那么这样的发布就应该走发布系统和发布流程,要被很好的测试、上线和回滚计划。关键是,走发布过程是可以被记录、追踪和回溯的,而在线上敲命令是完全无法追踪的。没人知道你敲了什么命令。

其二,真正良性的运维能力是——人管代码,代码管机器,而不是人管机器。你敲了什么命令没人知道,但是你写个工具做变更线上系统,这个工具干了什么事,看看工具的源码就知道了。

另外、有人说,以后不要用rm了,要用mv,还有人说,以后干这样的事时,一个人干,另一个人在旁边看,还有人说,要有一个checklist的强制流程做线上的变更,还有人说要增加一个权限系统。我觉得,这些虽然可以work,但是依然不好,再由如下:

其一、如果要解决一个事情需要加更多的人来做的事,那这事就做成劳动密集型了。今天我们的科技就是在努力消除人力成本,而不是在增加人力成本。而做为一个技术人员,解决问题的最好方式是努力使用技术手段,而不是使用更多的人肉手段。人类区别于动物的差别就是会发明和使用现代化的工具,而不是使用更多的人力。另外,这不仅仅因为是,人都是会有这样或那样的问题(疲惫、情绪化、急燥、冲动……),而机器是单一无脑不知疲惫的,更是因为,机器干活的效率和速度是比人肉高出N多倍的。

其二、增加一个权限系统或是别的一个watch dog的系统完全是在开倒车,权限系统中的权限谁来维护和审批?不仅仅是因为多出来的系统需要多出来的维护,关键是这个事就没有把问题解决在root上。除了为社会解决就业问题,别无好处,故障依然会发生,有权限的人一样会误操作。对于Gitlab这个问题,正如2nd Quadrant的CTO建议的那样,你需要的是一个自动化的备份和恢复的工具,而不是一个权限系统。

其三、像使用mv而不rm,搞一个checklist和一个更重的流程,更糟糕。这里的逻辑很简单,因为,1)这些规则需要人去学习和记忆,本质上来说,你本来就不相信人,所以你搞出了一些规则和流程,而这些规则和流程的执行,又依赖于人,换汤不换药,2)另外,写在纸面上的东西都是不可执行的,可以执行的就是只有程序,所以,为什么不把checklist和流程写成代码呢?(你可能会说程序也会犯错,是的,程序的错误是consistent,而人的错误是inconsistent)

最关键的是,数据丢失有各种各样的情况,不单单只是人员的误操作,比如,掉电、磁盘损坏、中病毒等等,在这些情况下,你设计的那些想流程、规则、人肉检查、权限系统、checklist等等统统都不管用了,这个时候,你觉得应该怎么做呢?是的,你会发现,你不得不用更好的技术去设计出一个高可用的系统!别无它法。

关于备份

一个系统是需要做数据备份的,但是,你会发现,Gitlab这个事中,就算所有的备份都可用,也不可避免地会有数据的丢失,或是也会有很多问题。理由如下:

1)备份通常来说都是周期性的,所以,如果你的数据丢失了,从你最近的备份恢复数据里,从备份时间到故障时间的数据都丢失了。

2)备份的数据会有版本不兼容的问题。比如,在你上次备份数据到故障期间,你对数据的scheme做了一次改动,或是你对数据做了一些调整,那么,你备份的数据就会和你线上的程序出现不兼容的情况。

3)有一些公司或是银行有灾备的数据中心,但是灾备的数据中心没有一天live过。等真正灾难来临需要live的时候,你就会发现,各种问题让你live不起来。你可以读一读几年前的这篇报道好好感受一下《以史为鉴 宁夏银行7月系统瘫痪最新解析

所以,在灾难来临的时候,你会发现你所设计精良的“备份系统”或是“灾备系统”就算是平时可以工作,但也会导致数据丢失,而且可能长期不用的备份系统很难恢复(比如应用、工具、数据的版本不兼容等问题)。

我之前写过一篇《分布式系统的事务处理》,你还记得下面这张图吗?看看 Data Loss 那一行的,在Backups, Master/Slave 和 Master/Master的架构下,都是会丢的。

所以说,如果你要让你的备份系统随时都可以用,那么你就要让它随时都Live着,而随时都Live着的多结点系统,基本上就是一个分布式的高可用的系统。因为,数据丢失的原因有很多种,比如掉电、磁盘损坏、中病毒等等,而那些流程、规则、人肉检查、权限系统、checklist等等都只是让人不要误操作,都不管用,这个时候,你不得不用更好的技术去设计出一个高可用的系统!别无它法。(重要的事,得再说一篇)

另外,你可以参看我的另一篇《关于高可用系统》,这篇文章中以MySQL为例,数据库的replication也只能达到 两个9。

AWS 的 S3 的的高可用是4个加11个9的持久性(所谓11个9的持久性durability,AWS是这样定义的,如果你存了1万个对象,那么丢一个的时间是1000万年),这意味着,不仅仅只是硬盘坏,机器掉电,整个机房挂了,其保证可以承受有两个设施的数据丢失,数据还是可用的。试想,如果你把数据的可用性通过技术做到了这个份上,那么,你还怕被人误删一个结点上的数据吗?

非技术方面

故障反思

一般说来,故障都需要反思,在Amazon,S2以上的故障都需要写COE(Correction of Errors),其中一节就是需要Ask 5 Whys,我发现在Gitlab的故障回顾的blog中第一段中也有说要在今天写个Ask 5 Whys。关于Ask 5 Whys,其实并不是亚马逊的玩法,这还是算一个业内常用的玩法,也就是说不断的为自己为为什么,直到找到问题的概本原因,这会逼着所有的当事人去学习和深究很多东西。在Wikipedia上有相关的词条 5 Whys,其中罗列了14条规则:

  1. 你需要找到正确的团队来完成这个故障反思。
  2. 使用纸或白板而不是电脑。
  3. 写下整个问题的过程,确保每个人都能看懂。
  4. 区别原因和症状。
  5. 特别注意因果关系。
  6. 说明Root Cause以及相关的证据。
  7. 5个为什么的答案需要是精确的。
  8. 寻找问题根源的步骤,而不是直接跳到结论。
  9. 要基础客观的事实、数据和知识。
  10. 评估过程而不是人。
  11. 千万不要把“人为失误”或是“工作不注意”当成问题的根源。
  12. 培养信任和真诚的气氛和文化。
  13. 不断的问“为什么”直到问题的根源被找到。这样可以保证同一个坑不会掉进去两次。
  14. 当你给出“为什么”的答案时,你应该从用户的角度来回答。

工程师文化

上述的这些观点,其实,我在我的以住的博客中都讲过很多遍了,你可以参看《什么是工程师文化?》以及《开发团队的效率》。其实,说白了就是这么一个事——如果你是一个技术公司,你就会更多的相信技术而不是管理。相信技术会用技术来解决问题,相信管理,那就只会有制度、流程和价值观来解决问题。

这个道理很简单,数据丢失有各种各样的情况,不单单只是人员的误操作,比如,掉电、磁盘损坏、中病毒等等,在这些情况下,你设计的那些流程、规则、人肉检查、权限系统、checklist等等统统都不管用,这个时候,你觉得应该怎么做呢?是的,你会发现,你不得不用更好的技术去设计出一个高可用的系统!别无它法。(重要的事得说三遍)

事件公开

很多公司基本上都是这样的套路,首先是极力掩盖,如果掩盖不了了就开始撒谎,撒不了谎了,就“文过饰非”、“避重就轻”、“转移视线”。然而,面对?;淖罴逊椒ň褪恰岸嘁恍┱娉?,少一些套路”,所谓的“多一些真诚”的最佳实践就是——“透明公开所有的信息”,Gitlab此次的这个事给大家树立了非常好的榜样。AWS也会把自己所有的故障和细节都批露出来。

事情本来就做错了,而公开所有的细节,会让大众少很多猜测的空间,有利于抵制流言和黑公关,同时,还会赢得大众的理解和支持??纯碐itlab这次还去YouTube上直播整个修复过程,是件很了不起的事,大家可以到他们的blog上看看,对于这样的透明和公开,一片好评。

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/17680.html/feed 56
Chrome开发者工具的小技巧 http://www.chinamxjy.com/articles/17634.html http://www.chinamxjy.com/articles/17634.html#comments Thu, 19 Jan 2017 12:25:55 +0000 http://www.chinamxjy.com/?p=17634 Read More Read More

]]>
Chrome的开发者工具是个很强大的东西,相信程序员们都不会陌生,不过有些小功能可能并不为大众所知,所以,写下这篇文章罗列一下可能你所不知道的功能,有的功能可能会比较实用,有的则不一定,也欢迎大家补充交流。

话不多话,我们开始。

代码格式化

有很多css/js的代码都会被 minify 掉,你可以点击代码窗口左下角的那个 { } ?标签,chrome会帮你给格式化掉。

强制DOM状态

有些HTML的DOM是有状态的,比如<a> 标签,其会有 active,hover, focus,visited这些状态,有时候,我们的CSS会来定关不同状态的样式,在分析网页查看网页上DOM的CSS样式时,我们可以点击CSS样式上的 :hov 这个小按钮来强制这个DOM的状态。

 

 

动画

现在的网页上都会有一些动画效果。在Chrome的开发者工具中,通过右上角的菜单中的 More Tools?=>?Animations 呼出相关的选项卡。于是你就可以慢动作播放动画了(可以点选 25%10%),然后,Chrome还可以帮你把动画录下来,你可以拉动动再画的过程,甚至可以做一些简单的修改。

 

直接编辑网页

在你的 console 里 输入下面的命令:

document.designMode = "on" 

于是你就可以直接修改网页上的内容了。

P.S. 下面这个抓屏中还演示了一个如何清空console的示例。你可以输入 clear() 或是 按 Ctrl+L(Windows下),CMD + K (Mac下)

 

网络限速

你可以设置你的网络的访问速度来模拟一个网络很慢的情况。

 

复制HTTP请求

这个是我很喜欢 的一个功能,你可以在 network选项卡里,点击 XHR 过滤相关的Ajax请求,然后在相关的请求上点鼠标右键,在菜单中选择: Copy => Copy as cURL,然后就可以到你的命令行下去 执行 curl 的命令了。这个可以很容易做一些自动化的测试。

 

友情提示:这个操作有可能会把你的个人隐私信息复制出去,比如你个人登录后的cookie。

抓个带手机的图

这个可能有点无聊了,不过我觉得挺有意思的。

在device显示中,先选择一个手机,然后在右上角选 Show Device Frame,然后你就看到手机的样子了,然后再到那个菜中中选 Capture snapshot,就可以抓下一个有手机样子的截图了。

我抓的图如下(当然,不是所有的手机都有frame的)

 

设置断点

除了给Javascript的源代码上设置断点调试,你还可以:

给DOM设置断点

选中一个DOM,然后在右键菜单中选 Break on … 你可以看到如下三个选项:

给XHR和Event Lisener设置断点

在 Sources 面页中,你可以看到右边的那堆break points中,除了上面我们说的给DOM设置断点,你还可以给XHR和Event Listener设置断点,载图如下:

关于Console中的技巧

DOM操作
  • chrome会帮你buffer 5个你查看过的DOM对象,你可以直接在Console中用 $0, $1, $2, $3, $4来访问。
  • 你还可以使用像jQuery那样的语法来获得DOM对象,如:$("#mydiv")
  • 你还可使用 $$(".class") 来选择所有满足条件的DOM对象。
  • 你可以使用 getEventListeners($("selector")) 来查看某个DOM对象上的事件(如下图所示)。

  • 你还可以使用 monitorEvents($("selector")) 来监控相关的事件。比如:
monitorEvents(document.body, "click");

Console中的一些函数

1)monitor函数

使用 monitor函数来监控一函数,如下面的示例

2)copy函数

copy函数可以把一个变量的值copy到剪贴板上。

3)inspect函数

inspect函数可以让你控制台跳到你需要查看的对象上。如:

更多的函数请参数官方文档 – Using the Console / Command Line Reference

Console的输出

我们知道,除了console.log之外,还有console.debug,console.info,console.warn,console.error这些不同级别的输出。另外一个鲜为人知的功能是,console.log中,你还可以对输出的文本加上css的样式,如下所示:

console.log("%c左耳朵", "font-size:90px;color:#888")

于是,你可以定义一些相关的log函数,如:

console.todo = function( msg){
  console.log( '%c%s %s %s', 'font-size:20px; color:yellow; background-color: blue;', '--', msg, '--');
}
console.important = function( msg){
  console.log( '%c%s %s %s', 'font-size:20px; color:brown; font-weight: bold; text-decoration: underline;', '--', msg, '--');
}

关于console.log中的格式化,你可以参看如下表格:

指示符 输出
%s 格式化输出一个字符串变量。
%i or %d 格式化输出一个整型变量的值。
%f 格式化输出一个浮点数变量的值。
%o 格式化输出一个DOM对象。
%O 格式化输出一个Javascript对象。
%c 为后面的字符串加上CSS样式

 

除了console.log打印js的数组,你还可以使用console.table来打印,如下所示:

var pets = [
  { animal: 'Horse', name: 'Pony', age: 23 },
  { animal: 'Dog', name: 'Snoopy', age: 13 },
  { animal: 'Cat', name: 'Tom', age: 18 },
  { animal: 'Mouse', name: 'Jerry', age: 12}
];
console.table(pets)

 

关于console对象

  • console对象除了上面的打日志的功能,其还有很多功能,比如:
  • console.trace() 可以打出js的函数调用栈
  • console.time() 和 console.timeEnd() 可以帮你计算一段代码间消耗的时间。
  • console.profile() 和 console.profileEnd() 可以让你查看CPU的消耗。
  • console.count() 可以让你看到相同的日志当前被打印的次数。
  • console.assert(expression, object) 可以让你assert一个表达式

这些东西都可以看看Google的Console API的文档。

其实,还有很多东西,你可以参看Google的官方文档 – Chrome DevTools

关于快捷键

点击在 DevTools的右上角的那三个坚排的小点,你会看到一个菜单,点选 Shortcuts,你就可以看到所有的快捷键了

如果你知道更多,也欢迎补充!

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/17634.html/feed 50
从 MongoDB “赎金事件” 看安全问题 http://www.chinamxjy.com/articles/17607.html http://www.chinamxjy.com/articles/17607.html#comments Sat, 07 Jan 2017 09:11:28 +0000 http://www.chinamxjy.com/?p=17607 Read More Read More

]]>
今天上午(2017年1月7日),我的微信群中同时出现了两个MongoDB被黑掉要赎金的情况,于是在调查过程中,发现了这个事件。这个事件应该是2017年开年的第一次比较大的安全事件吧,发现国内居然没有什么报道,国内安全圈也没有什么动静(当然,他们也许知道,只是不想说吧),Anyway,让我这个非安全领域的人来帮补补位。

事件回顾

这个事情应该是从2017年1月3日进入公众视野的,是由安全圈的大拿?Victor Gevers?(网名:0xDUDE,?的Chairman),其实,他早在2016年12月27日就发现了一些在互联网上用户的MongoDB没有任何的?;ご胧?,被攻击者把数据库删除了,并留下了一个叫 WARNING 的数据库,这张表的内容如下:

{
    "_id" : ObjectId("5859a0370b8e49f123fcc7da"),
    "mail" : "harak1r1@sigaint.org",
    "note" : "SEND 0.2 BTC TO THIS ADDRESS 13zaxGVjj9MNc2jyvDRhLyYpkCh323MsMq AND CONTACT THIS EMAIL WITH YOUR IP OF YOUR SERVER TO RECOVER YOUR DATABASE !"
}

基本上如下所示:

MongoDB ransom demand (via Victor Gevers)
MongoDB ransom demand (via Victor Gevers)

说白了就是黑客留下的东西——老子把你的MongoDB里的数据库给转走了,如果你要你的数据的话,给我0.2个的比特币(大约USD200)。然后,他的twitter上不断地发布这个“赎金事件”的跟踪报道。与此同时,中国区的V2EX上也发现了相关的攻击问题 《自己装的 mongo 没有设置密码结果被黑了

然后,在接下来的几天内,全球大约有1800个MongoDB的数据库被黑,这个行为来自一个叫 Harak1r1 的黑客组织(这个组织似乎就好黑MongoDB,据说他们历史上干了近8500个MongoDB的数据库,几乎都是在祼奔的MongoDB)。

不过,这个组织干了两天后就停手了,可能是因为这事已经引起了全球科技媒体的注意,产生了大量的报道(如果你在Google News里查一下“mongodb ransom”,你会看到大量的报道(中文社区中,只有台湾有相关的报道)),他们也许是不敢再搞下去了。

不过,很快,有几个copycats开始接着干,

马上跟进的是 own3d ,他们留下的数据库的名字叫 WARNING_ALERT,他们至少干掉了 930个MongoDB,赎金0.5个比特币(USD500),至少有3个用户付费了

然后是0704341626asdf,他们留下的数据库名字叫PWNED,他们至少干掉了740个MongoDB,赎金0.15个比特币(USD150),看看他们在数据库里留下的文字——你的MongoDB没有任何的认证,并且暴露在公网里(你TMD是怎么想的?)……

0704341626asdf group ransom note (via Victor Gerves)
0704341626asdf group ransom note (via Victor Gerves)

就在这两天,有两个新的黑客也来了

  • 先是kraken0,发现到现在1天了,干了13个MongoDB,赎金 0.1个比特币。
  • 然后是 3lix1r,发现到现在5个小时,干了17个MongoDB,赎金0.25比特币。

BBC新闻也于昨天报道了这一情况——《Web databases hit in ransom attacks》,现在这个事情应该是一个Big News了。

关于MongoDB的安全

安全问题从来都是需要多方面一起努力,但是安全问题最大的短板就是在用户这边。这次的这个事,说白了,就是用户没有给MongoDB设置上用户名和口令,然后还把服务公开到了公网上。

是的,这个安全事件,相当的匪夷所思,为什么这些用户要在公网上祼奔自己的数据库?他们的脑子是怎么想的?

让我们去看一下Shodan上可以看到的有多少个在暴露在公网上而且没有防范的MongoDB?我了个去!4万7千个,还是很触目惊心的(下图来自我刚刚创建的?Shodan关于MongoDB的报表

 

那么,怎么会有这么多的对外暴露的MongoDB?看了一下Shodan的报告,发现主要还是来自公有云平台,Amazon,Alibaba,Digital Ocean,OVH,Azure 的云平台上有很多这样的服务。不过,像AWS这样的云平台,有很完善的默认安全组设置和VPC是可以不把这样的后端服务暴露到公有云上的,为什么还会有那么多?

 

这么大量的暴露在公网上的服务是怎么回事?有人发现(参看这篇文章《It’s the Data, Stupid!》 ),MongoDB历史上一直都是把侦听端口绑在所有的IP上的,这个问题在5年前(2011年11月)就报给了MongoDB (SERVER-4216),结果2014年4月才解决掉。所以,他觉得可能似乎 MongoDB的 2.6之前的版本都会默认上侦听在0.0.0.0 。

于是我做了一个小试验,到我的Ubuntu 14.04上去?apt-get install mongodb(2.4.9版),然后我在/etc/mongodb.conf 文件中,看到了默认的配置是127.0.0.1,mongod启动也侦听在了127.0.0.1这台机器上。一切正常。不过,可能是时过境迁,debain的安装包里已加上了这个默认配置文件。不管怎么样,MongoDB似乎是有一些问题的。

再到Shodan上看到相关的在公网裸奔的MongoDB的版本如下,发现3.x的也是主流:

 

虽然,3.x的版本成为了主流,但是似乎,还是有很多人把MongoDB的服务开到了互联网上来,而且可以随意访问。

你看,我在阿里云随便找了几台机器,一登就登上去了。

真是如那些黑客中的邮件所说的:WTF,你们是怎么想的?

后续的反思

为什么还是有这么多的MongoDB在公网上祼奔呢?难道有这么多的用户都是小白?这个原因,是什么呢?我觉得可能会是如下两个原因:

1)一是技术人员下载了mongod的软包,一般来说,mongodb的压缩包只有binary文件 ,没有配置文件 ,所以直接解开后运行,结果就没有安全认证,也绑在了公网上。也许,MongoDB这么做的原因就是为了可以快速上手,不要在环境上花太多的时间,这个有助于软件方面的推广。但是,这样可能就坑了更多的人。

2)因为MongoDB是后端基础服务,所以,需要很多内部机器防问,按道理呢,应该绑定在内网IP上,但是呢,可能是技术人员不小心,绑在了0.0.0.0的IP上。

那么,这个问题在云平台上是否可以更好的解决呢?

关于公网的IP。一般来说,公有云平台上的虚拟主机都会有一个公网的IP地址,老实说,这并不是一个好的方法,因为有很多主机是不需要暴露到公网上的,所以,也就不需要使用公网IP,于是,就会出现弹性IP或虚拟路由器以及VPC这样的虚拟网络服务,这样用户在公有云就可以很容易的组网,也就没有必要每台机器都需要一个公网IP,使用云平台,最好还是使用组网方案比较好的平台。

关于安全组。在AWS上,你开一台EC2,会有一个非常严格的安全组——只暴露22端口,其它的全部对外网关闭。这样做,其实是可以帮用户防止一下不小心把不必要的服务Open到公网上。按道理来说,AWS上应该是帮用户防了这些的。但是,AWS上的MongoDB祼奔的机器数量是最多的,估计和AWS的EC2的 基数有关系吧(据说AWS有千万台左右的EC2了)

最后,提醒大家一下,被黑了也不要去付赎金,因为目前来说没有任何证据证明黑客们真正保存了你的数据,因为,被黑的服务器太多了,估计有几百T的数据,估计是不会为你保存的。下面也是Victor Gevers的提示:

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/17607.html/feed 41
技术人员的发展之路 http://www.chinamxjy.com/articles/17583.html http://www.chinamxjy.com/articles/17583.html#comments Wed, 28 Dec 2016 04:29:25 +0000 http://www.chinamxjy.com/?p=17583 Read More Read More

]]>
2012年的时候写过一篇叫《程序算法与人生选择》的文章,我用算法来类比如何做选择,说白了就是怎么去计算,但是并没有讲程序员可以发展的方向有哪些。 所以,就算是有这些所谓的方法论,我们可能对自己的发展还是会很纠结和无所事从,尤其是人到了30岁,这种彷徨和迷惑越来越重。虽然我之前也写过一篇《编程年龄和编程技能》的文章,但是还是有很多做技术的人对于自己能否在年纪大时还能去做技术感到没有信心。我猜测,这其中,最大的问题的是,目前从事技术工作的种种负面的经历(比如经常性的加班,被当成棋子或劳动力等等),让人完全看不到希望和前途,尤其是随着年纪越来越大,对未来的越来越没有信心。

同时,也是因为在GIAC的大会被问到,程序员老了怎么办?而在年底这段时间,也和几个朋友在交流中不断地重复谈到个人发展的这个话题。我的人生过半,活到“不惑”的年纪,自然经常性的对什么事都会回头看看总结归纳,所以,在交谈过程中和交谈过后,自己也有一些思考想记录下来。因为我本人也是在这条路上的人,所以,谈不上给他人指导,我同样也是在瞎乱折腾同样每天在思考自己要去哪儿的“一尘世间迷途老生”??銮?,我的经历和眼界非常有限,因此,下面的这些关于个人发展的文字和思考必然是受我的眼界和经历所局限的。也欢迎大家补充和指正。

这些东西不一定对,也不一定就是全部,期许可以让你在年底的时候有所思考,在明年的时候有所计划。

一个重要阶段和标志

在讲个人发展之前,我需要先说一下人生中的一个非常重要的阶段——20到30岁!

这个阶段的首要任务,就是提升自己学习能力和解决难题的能力。这是一个非常非常关键的时间段!这个时间段几乎决定着你的未来。

30岁以前,这个时间段,应该是人学习和积累的时间段,这个时间段,就是努力学习的时间段。这个时间段,你一定要把时间花在解决问题的技能上。就是说,你一定要练就成的技能是——你能解决大多数人不能解决的问题。使蛮力埋头加班苦干,当一个搬砖老黄牛的是肯定没有前途的。如果你不幸呆在了一个搬砖的地方,天天被业务压得喘不过气来,我建议你宁可让你的项目延期被老板骂,也要把时间挤出来努力学习基础知识,多掌握一些技术(很多技术在思路上是相通的),然后才能有机会改变自己目前的状况。因为,比起你的个人未来,项目延期被老板骂、绩效不好拿不到奖金,都不是什么事儿。

总结一下,你在30岁前,工作5-7年,你需要拥有:

  • 高效的学习能力。这意味着——基础知识扎实、触类旁通、读英文文档不费劲、有寻找前沿知识的能力、能够看到问题和技术的本质、善于思辩、能独立思考。
  • 解决问题的能力。这意味着——你要高效的学习能力、见过很多的场景、犯过或是处理很多错误、能够防火而不是救火。

如果你拥有这两个能力的现象是—— 在团队或身边的人群中的显现出Leadership。

Leadership并不是当领导和经理,而是一种特征,这种特征有如下两个简单的表象:

  • 帮人解问题。团队或身边中大多数人都在问:“这问题怎么办?”,而总是你能站出来告诉大家这事该怎么办?
  • 被人所依赖。团队或身边中大多数人在做比较关键的决定时,都会来找你咨询你的意见和想法。

一但你在在30岁之间出现了Leadership这样的特征,那么,你会进入一个正循环的阶段:

  • 因为你学习能力强,所以,你会有更多的机会解决难题。
  • 你有更多的机会解决难题,你就会学更多的东西,于是你就会更强。
  • 上面这个循环,只要循环上几年,就会让你人生的各种可能性大大的增加。

【 注意 】

  • 要达到这样的特质,需要找到自己的长处、以及适合自己的环境。就像鱼的特长是呆在水里,让鱼儿去追求陆上动物的刺激生活并不靠谱。
  • 一般说来,有这样的潜质的人,在学校中就应该要出现。如果你在大学中还没有出现这样的潜质,那么,你在工作当中要加倍努力了(注:所谓的加倍努力,不是让你使蛮力加班,而是让你多学习成长,使蛮力拼命是弥补不了能力、思维、眼界上的缺陷的)。
  • Leadership也有范围的,比如,身边的朋友,工作中的团队/部分,圈内,整个行业。Leadership的范围越大,你的个人发展的选择性就越高。反之则越小。
  • 如果已到了30岁左右,还是没有出现这样的特征。那么,可能未来你也很难有这样的Leadership了。而你的个人发展的可能性可能也就不多了(sigh…)

读到这里,我必需要说一下,如果你已开始显现出你的Leadership,那么你才谈得上个人发展,这篇文章后续的内容也可能才会对你有意义。

个人发展的三个方向

以我个人短浅的经历和视野,目前只看到的人的发展有如下三个大方向(他们之间可能会有重叠):

1)在职场中打拼

2)去经历有意义有价值的事

3)追求一种自由的生活

这三个方向,我个人或多或少都体验过,我也见过身边的很多人走这三个方向走的比较成功。也许还有别的方向,没办法,现在,我的视野就这么大,所以,我在这里,我主要就是谈谈这三个方向。Again,人有资格去走这三个方向的前提是——已有了上面我说的Leadership那种特质!

一、在职场中发展

在职场中发展应该是绝大多数人的选择。通过加入公司来达到人生的发展。

我们经??梢钥吹胶芏嗨降摹爸耙倒婊?,但是大多数职业规划只不过人力资源搞出来的东西,和实际其实是有很大出入的。我的人生经历中,有18年左右是在公司中度过的,在过银行,小公司,大公司,民营公司,外国公司,传统IT公司,互联网公司,不同的公司完全有不同的玩法和文化,我的经历还算丰富,但也不算特别成功,这里只分享一些我在职场中的心得(不一定对,仅供参考)。

1、去顶尖公司

去顶尖公司的一个目的就是让你的Leadership的范围的可能性扩大。

因为公司和公司的差距也不小,所以,就算你在低端公司里是骨干份子,但在高端公司里可能只是一个普通员工(就像中国足球队的主力到了英超可能都无法入?。?。所以,在职场中,如果你要让你的个人价值最大化的话,你一定要去顶尖的公司。因为顶尖公司里有非常不错的工作方法和场景,这并不是能看书或是交流得来的,这是必需要去亲身体验的。所以说,在顶尖公司掌握的技能,开阔的眼界,通常来说都会比低端公司的要多得多。

另外,每个公司的工作级别都是有相互对标的,比如:阿里的P几对应于百度的T几。国内的一线公司职位还相当,但是如果和国外一线公司的比,那就有差距了,而且差距还很大。比如,Google或Facebook的某个高级工程师,可能就对应于阿里的P8/P9甚至更高。

是的,对于职场来说,如果你在顶尖公司是骨干,那么,你去低端公司,则有很大机会会成为他们高管和核心。就好像你在Facebook里干三五年成为他们的技术骨干,那么你到BAT去成成为高管概率是非常大的。反过来,如果你毕业主去了BAT成为了一个螺丝钉,在天天加班中度过你的青春,你干个十年能成为BAT的高管的概率可能会非常的低。

2、去真正的创业公司

去顶尖公司和去创业公司在某些时候并不冲突。不过,这里我想讲的是,一个技术能力强的人在大公司可能会被埋没掉。因为大公司业务成功后,

  • 成功的公司在招聘各种高级技术人才都不会成为问题,于是少你一个不少,多你一个不多。
  • 成功的公司其整个技术体系已经完成,Legacy的问题也比较多,所以,可以供你发挥的余地不大。
  • 成功的公司更多的可能会想要稳定的系统,稳定必然会产生保守,而保守则产生不思进取。

所以,对于中高级人才来说,在大公司里的能产生的个人价值,可能远远不如那些求贤若渴、没有包袱、可以尽情施展、相对更为灵活和自由的创业型公司。

不过,去创业公司需要小心仔细的挑选和评估,创业公司的不确定因素很多,也和创始人的因素太大了,所以,你需要小心了解创始人和他们的业务情况,想法和理念差不多才能更好的共事。

好多创业公司其实并不是真正的创业公司,他们创业有很大的侥幸和驱利心理,要小心甄别。因为那不是真正的创业公司。

3、职业生涯的发展阶段

首先,有一个不争事实——整个社会是会把最重要的工作交给30岁左右的这群人的。也就是说,30岁左右这群人是这个社会的做事的中坚力量。

所以,这是一个机遇!如果你有了Leadership,你就一定能在这个时间段内赶得上这个机遇——公司和领导对你寄于信任和厚望,并把重要的团队和工作交给你。

于是,你的30岁到40岁就成了一个职业生涯的发展期,也就是你的事业上升期。如果你到40岁都没有赶上,那么你的职业生涯也就这样了,老有所成的人是少数。

在你事业的上升期,你需要更多的软技能,比如:

  • 带领产品和业务的发展的能力
  • 推行自己喜欢的文化的能力
  • 项目管理的能力——在任务重、时间紧中求全
  • 沟通和说服别人的能力
  • 解决冲突的能力
  • 管理和发展团队的能力
  • 解决突发事件的应急能力
  • …… ……

另外,你还要明白在职场里的几个冷酷的事实:

  • 你开始要关心并处理复杂的人事。尤其在大公司,大量的人都是屁股决定脑袋,利益关系复杂,目标不一致,每个人心里都有不一样的想法。这个时候再也不是talk is cheap, show me the code!而是,code is cheap,talk is the matter。你需要花大量的时间去思考和观察形形色色的人。需要耗费大量的精力在不同的人之间周旋,而不是花时间去创造些什么有价值的东西。
  • 你要开始学会使用各种政治手段。办公室政治不可避免,越大的公司越重,自从你开始成为一线的leader的那一天起,你就开始成为“里外不是人”的角色,需要在下属和领导,员工和公司之间周旋。随而你的级别越来越高,你需要使用更多的政治手段,你会学会审时度世的站队,学会迎合员工和领导,学会用官员的语言说话,学会此一时彼一时,学会妥协和交换,学会忍气吞声,学会在在适当的时机表现自己,学会波澜不惊,学会把自己隐藏起来,甚至你还会迷失自我,开始学会一些厚黑学,比如不得不在适当的时机在背后捅人刀子……你可能会成为一个你自己都讨厌的人

听上去真的好无聊,所以,你现在也明白为什么高层们都看上去很忙很累,而且抽不出时间来关心细节问题,因为,他们更多的是要协调整个组织和系统来运转,甚至还要四处周旋,各种博弈,没办法,这是职场的必需的东西!听起来是不是感觉人类很愚蠢?这真是没办法的事。如果你不想或是也没有能力玩这些东西,那么你需要去那些可以让技术人员安安心心做技术的公司。这类的公司,我见过Microsoft、Google、Amazon或是一些创业公司里都有。国内的大公司中也有让技术人员成长的职业成长线,但老实说,表面上看似是一个让人专心做技术的升职成长线,但其实还是管理岗位。

所以,技术人员在职场中的归宿有两条路 —— 到真正的技术公司成为一个专心做技术的人,或是在成为一个职业的经理人。

 

二、追求人生的经历

先说三个故事,

  • 第一个,是在阿里的时候,有一天在内网里看到一个贴子,一个做产品的女孩说自己准备离职要去法国学烘培厨艺,引得大家热评。
  • 第二个,是在亚马逊的美国老板,他每年都要去报个培训班学一个技能,比如:厨艺、开双翼飞机、夜总会里的DJ……、甚至去华盛顿去学当一个政客。
  • 第三个,是在汤森路透工作时,一个英国的同事,有一天他说他离职了,和自己的老婆准备用余生去周游世界,我问他是不是有足够多的钱了?他和我说,钱不够,他俩口子的计划是,边旅游边打工,打工打够到下一站的钱就走。他还说,那种用假期去另一个城市的旅游太没意思了,如果你不在那个地方生活上一段时间 ,你怎么能算是好的旅游体验呢?好吧,无法反驳。

我是觉得他们把自己的人生过得如此有意思,令我很佩服。虽然跨界跨得有点猛,但是 Why Not?

在这里,我想说,去追求一种和众人不一样的人生经历也是一件挺好的事,我个人感觉,比起在职场里有趣地多多了。如果你厌倦了职场,其实为什么不去追求一下不同的人生经历呢。就算你不想去追求跨度比较大的人生经历,那么,在技术圈里,也有很多有价值有意思的经历也可以去的。追求刺激有意义的与众不同的经历的人,其实也能算是一种人生的成功,不是吗?

如果只说技术方面,我个人看到的去追求经历的人,有两种追求的人其实也很成功的:

  • 到技术创新的发源地去经历创新。计算机互联网各种技术的创新引擎,基本上来说,就是在美国了。我们赶上了这个时代,也选对了这个时代最火热的行业,那么,有什么理由不去这个时代的技术发动机那里去经历呢?在美国硅谷湾区,无论是大公司,还是创业公司,都在迸发着各式各样的创新,如果有能力有机会,为什么不努力去经历一下呢?不经历一下,老了不会觉得错过了是一种后悔吗?
  • 去经历下一个热点技术的发展。从IT,到互联网、再到移动互联网、云计算、大数据,再到未来的AI,VR,IoT……,技术创新的浪潮一波接一波的过来,你是想在那继续搬砖搬下去,是想迎浪而上去经历浪潮,还是想成为一个随波逐流的人?

打工也好,创业也好,在国内也好,在国外也好,这些都是形式,不是内容。内容则是你有没有和有想法的人去经历有意义有价值事?人生苦短,白驹过隙,我们技术人员最大的幸运就是生在这样一个刺激的时代,那么,你还有什么理由不去追逐这些前沿刺激的经历呢?

三、追求自由的生活

我相信“自由”这个事,是所有人的心中都会想去追求的?!吧峡晒?,爱情价更高,…… ”(哈哈)

但一说起自由,绝大多数人都想到的是“财富自由”或是“财务自由”,其实,并不完全是这样的,在自由的通路上,我个人的经历告诉我,其实,你会有很多的不同类型的自由。下面,是我对几个层次的“自由”的理解。

第一层自由——工作自由。人的第一层自由的境界是——“工作自由”,我到不是说你在工作单位上可以很自由,虽然有特例,但并不普遍。我想说的“工作自由”是——你不会有失业?;辛?。也就是说,你成了各个公司的抢手货,你不但不愁找不到工作,而且你是完全不愁找不到好工作。试想一下,如果是工作来找你,一方面,你就有真正意义上的工作选择权了,另一方面,你都不愁工作了,你完全就可以随时离职去干你想干的事了。此时,你就达到了“工作自由”。

第二层自由——技能自由。工作自由已是不错,不过前提是你还是需要依赖于别人提供的工作机会。而技能自由则是你可以用自己的技能养活自己,而不需要去公司里工作。也就是所谓的自由职业者了,社会上,这样的人也不少,比如,一些健身体育教练、设计师、翻译者、作者……这些都可以算是自由职业者,程序员这个职业中只要不是搬砖的,有想法的,就有可以成为自由积业者的潜质,想一想,你拥有的编程能力,其实是一种创造的能力,也就是创造力,只要你Make Something People Want(YC创业公司的slogan),你是完全可以通过自己的技能来养活自己的。如果你通过某些自动化的东西,或是你在App上做了一个软件个体户,让自己的收入不断,甚至你做了一个开源软件,社区每个月都给你捐款捐到比你打工挣的还多,那么你就真正的有了技能自由了。

第三层自由——物质自由。我把财务自由换了一种说法。我个人觉得,除了有个好爸爸之外这种特例的情况,如果你想有物质自由的话,本质上来说,你一定要学会投资,投资不一定是你的钱,时间也是一种财富,年轻更是,你怎么投资你的时间还有你的青春?你要把你的投资投到什么样的事,什么样的人?对于投资这个事,风险也比较大。但是,人生不敢冒险可能才是最大的冒险。这个世界有很多技术不是你能看书学来的,而要只能在实战中学会的,比如:游泳。投资可能也是一种。只有真正懂投资的人,或是运气非常好的人,才可能实现物质自由。

追求自由的生活,其实也是个人发展道路上的一个不错的选择。通常来说,自由的人,能力都不差,钱也不会少。因为,他们懂得投资。

也就是说,拥有追求自由能力的的人,

  • 不但有领导力和创造力(也可指导大多数人并走在大多数人前面)
  • 同时他还懂得怎么投资(知道时间和精力和金钱应该投在什么地方)

(注:这里我没有提精神自由,老实说,精神上的自由我也不清楚是什么东西,因为我还没有见过,眼界有限,所以先按不表了,不然真成鸡汤文了)

总结

无论是在职场中打拼,还是追求精彩的经历,还是去实现自由,我觉得都是不错的个人发展的方向。

他们都有重叠,比如:

  • 你可以在职场中去追求那些刺激的经历的公司。
  • 同样也可以通过加入有潜力高速发展的公司来达到自由。
  • 你也可以通过追寻不一样的经历来达到人生的自由。
  • ……

总之,这里的逻辑是——

  • 能够去规划自己的个人发展的人,通常都是有很多机会和可能性的人。
  • 有很多机会和可能性的人,通常都是有Leadership,喜欢冒险的人。
  • 有Leadership喜欢冒险的人,通常都是学习能力强,思维活跃,喜欢折腾,懂得“投资”的人。
  • 学习能力强思维活跃的人,通常来说,都是喜欢看书,喜欢实践和新鲜事物,不怕艰难和挑战,用智力而不是使蛮力的人。
  • 懂得“投资”的人,通常来说,他们更多的关注的是未来和长远的成长,而不是当下的KPI、奖金和晋升。

 

电影《飞屋环游记》
插图来自电影《飞屋环游记》

最后祝大家新年快乐,来年大展鸿图。

(全文完)

 


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/17583.html/feed 154
如何读懂并写出装逼的函数式代码 http://www.chinamxjy.com/articles/17524.html http://www.chinamxjy.com/articles/17524.html#comments Sun, 23 Oct 2016 09:56:29 +0000 http://www.chinamxjy.com/?p=17524 Read More Read More

]]>
drawing-recursive今天在微博上看到了 有人分享了下面的这段函数式代码,我把代码贴到下面,不过我对原来的代码略有改动,对于函数式的版本,咋一看,的确令人非常费解,仔细看一下,你可能就晕掉了,似乎完全就是天书,看上去非常装逼,哈哈。不过,我感觉解析那段函数式的代码可能会一个比较有趣过程,而且,我以前写过一篇《函数式编程》的入门式的文章,正好可以用这个例子,再升华一下原来的那篇文章,顺便可以向大家更好的介绍很多基础知识,所以写下这篇文章。

先看代码

这个代码平淡无奇,就是从一个数组中找到一个数,O(n)的算法,找不到就返回 null。

下面是正常的 old-school 的方式。不用多说。

//正常的版本
function find (x, y) {
  for ( let i = 0; i < x.length; i++ ) {
    if ( x[i] == y ) return i;
  }
  return null;
}

let arr = [0,1,2,3,4,5]
console.log(find(arr, 2))
console.log(find(arr, 8))

结果到了函数式成了下面这个样子(好像上面的那些代码在下面若影若现,不过又有点不太一样,为了消掉if语言,让其看上去更像一个表达式,动用了 ? 号表达式):

//函数式的版本
const find = ( f => f(f) ) ( f =>
  (next => (x, y, i = 0) =>
    ( i >= x.length) ?? null :
      ( x[i] == y ) ? i :
        next(x, y, i+1))((...args) =>
          (f(f))(...args)))

let arr = [0,1,2,3,4,5]
console.log(find(arr, 2))
console.log(find(arr, 8))

为了讲清这个代码,需要先补充一些知识。

Javascript的箭头函数

首先先简单说明一下,ECMAScript2015 引入的箭头表达式。箭头函数其实都是匿名函数,其基本语法如下:

(param1, param2, …, paramN) => { statements } 
(param1, param2, …, paramN) => expression
     // 等于 :  => { return expression; } 

// 只有一个参数时,括号才可以不加:
(singleParam) => { statements }
singleParam => { statements }

//如果没有参数,就一定要加括号:
() => { statements }

下面是一些示例:

var simple = a => a > 15 ? 15 : a; 
simple(16); // 15
simple(10); // 10

let max = (a, b) => a > b ? a : b;

// Easy array filtering, mapping, ...

var arr = [5, 6, 13, 0, 1, 18, 23];
var sum = arr.reduce((a, b) => a + b);  // 66
var even = arr.filter(v => v % 2 == 0); // [6, 0, 18]
var double = arr.map(v => v * 2);       // [10, 12, 26, 0, 2, 36, 46]

看上去不复杂吧。不过,上面前两个 simple 和 max 的例子都把这箭头函数赋值给了一个变量,于是它就有了一个名字。有时候,某些函数在声明的时候就是调用的时候,尤其是函数式编程中,一个函数还对外返回函数的时候。比如下在这个例子:

function MakePowerFn(power) {
  return function PowerFn(base) {
    return Math.pow(base, power);
  } 
}

power3 = MakePowerFn(3); //制造一个X的3次方的函数
power2 = MakePowerFn(2); //制造一个X的2次方的函数

console.log(power3(10)); //10的3次方 = 1000
console.log(power2(10)); //10的2次方 = 100

其实,在 MakePowerFn 函数里的那个 PowerFn 根本不需要命名,完全可以写成:

function MakePowerFn(power) {
  return function(base) {
    return Math.pow(base, power);
  } 
}

如果用箭头函数,可以写成:

MakePowerFn = power  => {
  return base => {
    return Math.pow(base, power);
  } 
}

我们还可以写得更简洁(如果用表达式的话,就不需要 { 和 }, 以及 return 语句 ):

MakePowerFn = power => base => Math.pow(base, power)

我还是加上括号,和换行可能会更清楚一些:

MakePowerFn = (power) => (
  (base) => (Math.pow(base, power))
)

好了,有了上面的知识,我们就可以进入一个更高级的话题——匿名函数的递归。

匿名函数的递归

函数式编程立志于用函数表达式消除有状态的函数,以及for/while循环,所以,在函数式编程的世界里是不应该用for/while循环的,而要改用递归(递归的性能很差,所以,一般是用尾递归来做优化,也就是把函数的计算的状态当成参数一层一层的往下传递,这样语言的编译器或解释器就不需要用函数栈来帮你保存函数的内部变量的状态了)。

好了,那么,匿名函数的递归该怎么做?

一般来说,递归的代码就是函数自己调用自己,比如我们求阶乘的代码:

function fact(n){
  return n==0 ? 1 :  n * fact(n-1);
};
result = fact(5);

在匿名函数下,这个递归该怎么写呢?对于匿名函数来说,我们可以把匿名函数当成一个参数传给另外一个函数,因为函数的参数有名字,所以就可以调用自己了。 如下所示:

function combinator(func) {
  func(func);
}

这个是不是有点作弊的嫌疑?Anyway,我们再往下,把上面这个函数整成箭头函数式的匿名函数的样子。

(func) => (func(func)) 

现在你似乎就不像作弊了吧。把上面那个求阶乘的函数套进来是这个样子:

首先,先重构一下fact,把fact中自己调用自己的名字去掉:

function fact(func, n) {
  return n==0 ? 1 :  n * func(func, n-1);
}

fact(fact, 5); //输出120

然后,我们再把上面这个版本变成箭头函数的匿名函数版:

var fact = (func, n) => ( n==0 ? 1 :  n * func(func, n-1) )
fact(fact, 5)

这里,我们依然还要用一个fact来保存这个匿名函数,我们继续,我们要让匿名函数声明的时候,就自己调用自己。

也就是说,我们要把

(func, n) => ( n==0 ? 1 :  n * func(func, n-1) )

这个函数当成调用参数,传给下面这个函数:

(func, x) => func(func, x) 

最终我们得到下面的代码:

 
( (func, x) => func(func, x) ) (  //函数体
  (func, n) => ( n==0 ? 1 :  n * func(func, n-1) ), //第一个调用参数
  5 //第二调用参数
); 

好像有点绕,anyway, 你看懂了吗?没事,我们继续。

动用高阶函数的递归

但是上面这个递归的匿名函数在自己调用自己,所以,代码中有hard code的实参。我们想实参去掉,如何去掉呢?我们可以参考前面说过的那个 MakePowerFn 的例子,不过这回是递归版的高阶函数了。

HighOrderFact = function(func){
  return function(n){
    return n==0 ? 1 : n * func(func)(n-1);
  };
};

我们可以看,上面的代码简单说来就是,需要一个函数做参数,然后返回这个函数的递归版本。那么,我们怎么调用呢?

fact = HighOrderFact(HighOrderFact);
fact(5); 

连起来写就是:

HighOrderFact ( HighOrderFact ) ( 5 )

但是,这样让用户来调用很不爽,所以,以我们一个函数把 HighOrderFact ( HighOrderFact ) 给代理一下:

fact = function ( hifunc ) {
  return hifunc ( hifunc );
} (
  //调用参数是一个函数
  function (func) { 
    return function(n){
      return n==0 ? 1 : n * func(func)(n-1);
    };
  }
);

fact(5); //于是我们就可以直接使用了

用箭头函数重构一下,是不是简洁了一些?

fact = (highfunc => highfunc ( highfunc ) ) (
  func => n =>  n==0 ? 1 : n * func(func)(n-1)
);

上面就是我们最终版的阶乘的函数式代码。

回顾之前的程序

我们再来看那个查找数组的正常程序:

//正常的版本
function find (x, y) {
  for ( let i = 0; i < x.length; i++ ) {
    if ( x[i] == y ) return i;
  }
  return null;
}

先把for干掉,搞成递归版本:

function find (x, y, i=0) {
  if ( i >= x.length ) return null;
  if ( x[i] == y ) return i;
  return find(x, y, i+1);
}

然后,写出带实参的匿名函数的版本(注:其中的if代码被重构成了 ?号表达式):

( (func, x, y, i) => func(func, x, y, i) ) (  //函数体
  (func, x, y, i=0) => (
      i >= x.length ?  null :
         x[i] == y  ?  i : func (func, x, y, i+1)
  ), //第一个调用参数
  arr, //第二调用参数
  2 //第三调用参数
)

最后,引入高阶函数,去除实参:

const find = ( highfunc => highfunc( highfunc ) ) (
   func => (x, y, i = 0) => (
     i >= x.length ?  null :
           x[i] == y  ?  i : func (func) (x, y, i+1)
   )
);

注:函数式编程装逼时一定要用const字符,这表示我写的函数里的状态是 immutable 的,天生骄傲!

再注:我写的这个比原来版的那个简单了很多,原来版本的那个又在函数中套了一套 next, 而且还动用了不定参数,当然,如果你想装逼装到天上的,理论上来说,你可以套N层,呵呵。

现在,你可以体会到,如此逼装的是怎么来的了吧?。

其它

你还别说这就是装逼,简单来说,我们可以使用数学的方式来完成对复杂问题的描述,那怕是递归。其实,这并不是新鲜的东西,这是Alonzo Church 和 Haskell Curry 上世纪30年代提出来的东西,这个就是 Y Combinator 的玩法,关于这个东西,你可以看看下面两篇文章:

The Y Combinator (Slight Return)》,

Wikipedia: Fixed-point combinator

(全文完)


关注CoolShell微信公众账号可以在手机端搜索文章

(转载本站文章请注明作者和出处 betway手机客户端 ,请勿用于任何商业用途)

——=== 访问 酷壳404页面 寻找遗失儿童。 ===——
]]>
http://www.chinamxjy.com/articles/17524.html/feed 65