工作中的期权思维(全)

最近在《得到》APP 听万维钢老师的《精英日课 III》收获挺多的。有一种『自己冥思苦想数载,还说不清道不明,别人轻描淡写数语,说得通透清晰』的感觉。 先是关于博弈论的话题,其次是最近关于期权思维的话题,都讲得我恍然大悟。 这两天讲一讲万维钢老师《期权的智慧》这个系列文章的读后感。 1. 什么是期权思维 期权(option)是指一种选择的权利。不是选择『A/B/C/D』不同选项的权利,而是选或不选的权利。 有点绕。拿吃安眠药举例。一个人有失眠的毛病,晚上躺下担心睡不着,可是越担心越睡不着。怎么办呢?就是吃安眠药。头两次,安眠药效果特别好,吃了药躺下,立马能睡着,于是这个人再也不用担心失眠了。因为药放在家里,万一失眠,随时可以吃,睡觉时再也没有了担心,所以更加容易入睡。这样,晚上睡觉前吃安眠药,就成了可选项(option),也就是期权,可以选择吃,也可以选择不吃。option 是一种权利,而非义务。 权利常常伴随着义务。像谈婚论嫁这种事。古代,家长为自己孩子定了一门亲事,对方家条件不错——这桩亲事既是权利,也是义务。撕毁婚约的道德风险太高。定亲就是不可选项。而今天的一个女神,如果身边有个备胎随时愿意跟她结婚,但是女神也可以选择别人,这才叫可选项(option)。 (比如美国)股票市场中,有两种类型的期权,一种叫看涨期权(call option),一种叫看跌期权(put option)。因为英文表意更为准确,对延伸理解期权帮助更大,因此后面涉及概念,我都用英文。 call option 的含义是,它允许你在约定的时间,以约定的价格,买入一只特定的股票。call 代表买入,option 代表这是可选项。期权到期,买或者不买这只股票,是你的权利,是可选项(option)。 put option 的含义是,它允许你在约定的时间,以约定的价格,卖出一只特定的股票。put 代表放出。期权到期,卖或者不卖这只股票,是你的权利,是可选项(option)。 我做了一张图来帮助你理解其中的含义。 期权也是一种保险,对抗波动的保险。 比如,你持有一家公司的股票,你长期看好它,希望长期持有。可是最近大形势不太好,你感觉有下跌的风险,但是你又不想卖,怎么办? 用股票期权的办法,你可以买这只股票的 put option。如果股票当真跌了,因为你有 put,有一个被承诺的 put 价格,因此它跌再多,跟你都没关系。期权到期你总可以用当初约定的价格卖出它。你的损失最多也就是当初买 put 的那点钱。你的损失有一个上限。 同样道理,如果你手里的股票最近太热了,它可能在一个高点,你想再等等,可是又怕蒙受损失。那你应该买交割价格比当前价高一些的 call option。如果股票真的下跌,你卖掉的 call option 会变得不值钱,买你 call 的人就不会行使他的权力,你等于白赚了 call 的钱。如果股票反而涨上去了,那你不得不把股票卖出去,不过交割价格比你卖 call 时候的价格还高,你还是赚了一笔。 卖 option 的时候,卖出一种权力,得到一些收益,同时也卖出了(对抗波动的)风险。这就是期权的概念。 讲了这么多期权的概念。那么什么叫期权思维呢?就是利用期权的原理,重新解释生活中的现象。 2. 万老师的洞见 万老师就期权思维提出了几个洞见,非常发人深省。对以前没怎么接触过期权,更不要说具备期权思维的人,这些洞见的触动非常大。 2.1. 『期权只是权利,而非义务』 首先你得认识到,期权是权利,而非义务。 你购买了期权,其实是购买了一种权利,期权到期时,根据波动的情况,你可以选择行权,也可以选择弃权。 第一个是房地产的案例。有家开发商在新规划的地块上建房,现在一切还在图纸上,一年后才能交房。现在可以跟开发商先签约,谈好价格,一年后再买入。开发商为确保你不违约,要求你缴纳一笔抵押金( 万老师这里用『抵押金』一词,我理解『保证金』更符合我们的直觉。是笔误?还是美国的房产市场跟中国不一样? )。用期权思维,这相当于用抵押金买了一个 call。如果一年后房子升值,你有权以当初的低价买入这套房子;如果房价跌了,你大可违约,无非就是损失掉那一点抵押金。因此,正确的操作是多签几份合约,等房屋升值,再把这些合约转手卖出去。万一房屋没有升值,你损失的,也就是买 call 的钱,也就是那点抵押金。但房屋升值,你的收益上不封顶。 上面这个例子,我理解万老师讲的是美国房产市场。在中国,你跟开发商签订的合约,实际上没办法转手卖出去。开发商不会允许你赚走本来应该由他来赚的溢价。开发商不需要你给他的收益上保险。因为在中国,房价上涨是大概率事件。期房合约是一个无法交易的 call。 因为 option 是权利,所以买入 option 需要付代价。例如,买入股票期权,代价就是钞票。你需要购买期权。……

阅读全文

『每个架构师都应该研究下康威定律』

InfoQ 中国在 2016 年,发表过一篇文章,杨波的《每个架构师都应该研究下康威定律》。这篇文章对当时的我,触动是非常深刻的。一些说不清道不明的经验,被别人用浅显易懂的道理,讲得一清二楚。 康威定律是很早就听说过的,后来陆续又有一些接触,每次时隔一段时间再做了解,就会有非常深的触动。我理解,原因无他,因为它聚焦在组织架构和系统设计的关系上,而这两者,一个是架构师目标,一个是架构师的手段/工具。文中用很简短的一句话,讲清楚了这中间的关系。 系统架构的目标是解决利益相关者的关注点。 这句话简直太重要,太精妙了。 1. 架构师的目标,是各个利益相关者的关注点 很多人对架构师的误解,都以为是架构师是技术执行,是 top-level coder,对 coding 的结果负责。这就犯了以表象取人的问题。为什么?我后面再提。 架构师首先应该关注的,是项目中,各个角色,各个利益相关者,他们的利益诉求,他们在项目中的焦点。根据这些焦点,得到一个权衡的方案,并取得最大限度的支持。 2. 架构是权衡的艺术 权衡的英文表述比较准确一些。trade-off 。利益交易和平衡。 权衡的方法是博弈,无论是纳什均衡还是帕累托最优,权衡目标是达成一个相对稳定的博弈结果。这个结果,就是架构的目标需求。 所以你看,脱离实际场景谈『架构』,本来就是虚空的。 3. 架构首先是业务架构,其次才是技术架构 道理很简单,业务架构往往涉及最直接的利益分配,从市场到产品到后勤保障,通常都对业务指标虎视眈眈。产品技术指标他们并不关心。 从工作流程上来讲,业务架构决定产品设计,产品设计决定技术设计。说业务架构是技术架构的前置步骤,一点不为过。 唯一的例外,可能就是大厂里面做平台产品研发的案例了。从无到有形成一个平台,比如阿里 IaaS 云。商业模式不清晰,业务架构反而受制于技术架构。不过这种机会今后出现的可能性,越来越小。 4. 技术架构是工具/手段 确定了各个 stakeholder 的 key points,剩下就是怎么做的事情了。技术手段、技术架构,不过是实现平衡的工具而已。通过技术架构,将权衡的方案,表达出来,这是一个称职的架构师,秀于外的工作。 我个人对架构师的定义是,以权衡项目中各个利益相关方的利益关注点为目标,以技术设计为工具和手段,以持续的产品技术服务为交付物的产品研发决策者。 所以回过头去看,架构师的工作中,技术架构的部分,优先级排不到前列,称得上是最基础、最『本分』的技能。技术好,技术设计灵活,不是一名架构师值得炫耀的资本。架构师值得炫耀的,是他能够在复杂纷扰的环境中,仍然可以理出线头,正确判断形势,做出合理的架构设计。 比方说,一名做 ToB 业务的 SaaS 平台架构师,既往工作中,以项目经理/甲方的利益诉求为主,以己方销售的利益诉求为辅,养成了习惯。一个需求做不做,怎么做,第一问己方销售/甲方,其次问项目经理,总可以得到答案。有一天,他去到一家做 toC 产品的公司任架构师,他面临的 stakeholders 发生了翻天覆地的变化,『甲方』成了成千上万的个体,怎么去问每个个体,他们的 key points 是什么?所以这位架构师的转变是,以直接上级的利益诉求为主,以产品经理的利益诉求为辅。那么,这个架构师,很明显就犯了最低级的失职。即便他的技术实力再强,首先目标就错了,谈何取得胜利? 雷军讲的,以战术上的勤奋,掩盖战略上的懒惰,大概也是说这个意思。 啰嗦一句。无论是 toC 产品还是 toB 产品,架构师首先应该予以重视的 stakeholder,都应该是财务上销项对应的一方。也就是为公司提供入账的一方。有人可能会觉得奇怪,toC 产品不应该是用户为首要的 stakeholder 吗?真不一定。如果是付费用户,那么他们是公司账上销项对应的一方,他们算首要的 stackholder。如果用户是免费使用公司服务,那么应该把他们看做产品/服务的一部分,把他们看做产品/服务的资源,而不是 stackholder。既然是资源,能为己所用就可以;既然是产品的一部分,只要产品不散就可以。不需要过多考虑免费用户的诉求和偏好。 有些免费产品讲情怀,前提是他们活着不成问题。没干爹可抱的企业,先把自己的财务账算清楚,努力维持公司现金流为正,先有资本活下去,才是正道。别人在山顶为踏足云顶做赋,那是情怀,你在山底谈云,那是浮云。 5. 架构不止『偏技术』,不是每一名架构师都需要『偏管理』的搭档 架构师的责任,是交付能够让至少大多数 stakeholder 满意的架构方案,并且落地执行,交付一个 predictable 的结果。……

阅读全文

从 hexo 搬迁到 hugo

说是第一篇文章,其实是转到 Hugo 以后的第一篇文章。 至于转到 hugo 的原因,见下面的两篇文章。 hexo 又报 package 的依赖问题了 hexo 又成了技术流的玩具 总的来说,就是 npm 对 package 的依赖管理松散,再加上 hexo 社区对一些常用 plugins 惰于升级维护,导致 dependencies 经常冲突。升级不是,不升级也不是。最后干脆什么都用不了。 以前是重新安装一个 hexo 环境,还有几率能解决依赖的问题(部分 plugins 会降级安装)。但既然已经不是第一次遇到这种情况,问题的根源解决不了,没准儿以后还会遇到,干脆下定决心弃坑 hexo。 hugo 早就听说大名,golang 也是我喜欢的。基本上没调研其它 blog service,直接开始研究起 hugo 来。 1. 安装 hugo 我用 MacBook Pro,装了 HomeBrew,安装 hugo 相对简单。 brew install hugo 2. 建立站点 hugo new site my-blog 完成以后,my-blog 目录下会有以下子目录。 archetypes: 下面有一个 default.md 的模板,是新建文章的时候,会用到的模板。 config.toml: TOML 格式的配置文件。 content: 放文章源文件,.……

阅读全文

hexo 又报 package 的依赖问题了

因为 hexo 的 package 的依赖问题,特别是对彼此版本的依赖问题,折腾过两三次,一直没有特别好的解决办法。 node 本质上仍然是脚本语言,不像编译型语言,实在不行,还可以把 package 一个一个打成 binary,逐个消除 package 的依赖问题。node 做不到。当两个以上的 package 声明的依赖相互冲突时,这个项目基本上也就废了。没法儿正常使用了。 有人会问,怎么可能出现这样的情况?开发者发现不了吗? 开发者可能还真发现不了。首先,开发者的环境是既有的,是缓慢生长起来的,不是什么问题都能发现的。其次,CI 也不一定能发现问题。有些基础的 package 为了自身兼容性,对不同 node 环境做了兼容处理,在不同版本的 node 下,逻辑代码不同。再次,npm 的 peerDependencies 对 package 之间的依赖关系进行了解耦,有些依赖关系非强制,实际上是允许了冲突的存在。最后,node 的环境隔离方案,类似 pyenv 这样的,也有,非主流,而且治标不治本,仍然解决不了 package 之间的冲突。 之前我遇到的问题是 peerDependencies 导致的。今天遇到的问题,则是对 node 版本的声明导致的。 error nunjucks@3.1.3: The engine “node” is incompatible with this module. Expected version “>= 6.9.0 <= 11.0.0-0”. Got “12.4.0” error Found incompatible module 我的 node 是通过 HomeBrew 安装的,latest,当前版本 *v12.4.0*。 对 node 一直有一点担心,然后这种担心在 2016 年左右,逐渐成了现实。那就是 npm 对 package 的依赖管理策略。越松散,越自由,就越极客,越小众;越独裁,越限制,就越方便,越大众。npm 很明显走前者的路线,而且偏向极端。我知道稍微有点能力的公司,用 RN/Vue/Angular…… 都是自己搭 package server,自己造 package。包括一些基础的 package。没别的,就为一条,质量可控。……

阅读全文

Mac 下 VirtualBox 系统扩展不兼容的错误修复

Mac 上升级 VirtualBox 6.0.8,遇到一个报错,一直搞不定。大意是 system extension incompatible。提示框不是 warning 或者 error 图标,就是普通的 performance 图标,而且只出现一次,再安装,不会出现。 网络上没有结论,大多是说在 Performance 里面做安全授权。然后我遇到的并不是这个问题,Performance 里面没有授权提示。于是自己试着用降级的办法,安装 5.2.30,还是不行,同样的错误。再降级,到 5.2.28,终于行了,安装成功。 打开 5.2.28,发现有个提示,说有磁盘镜像失效,打开管理工具,发现是之前装的 Nox,在 VirtualBox 的配置中写入了 Nox 自己的镜像。卸载 Nox 的时候,Nox 没有从 VirtualBox 的配置中删除 Nox 的磁盘镜像。于是手动确认删除 Nox 相关的两个镜像。再进入 VirtualBox 就好了。 今天忽然想起来,也许就是因为失效镜像,导致升级失败呢。于是再安装 VirtualBox 试试。果然,就行了。 结论 对 VirtualBox 的失效镜像,一定要自行观察,手动清除,不能听之任之,容易造成潜在的问题。有一些模拟器啥的,安装的时候容易,卸载的时候麻烦,只能靠自己多留个心眼。……

阅读全文

外贸/跨境电商/代购/全球购/海淘适用的优惠

Vultr 是一款国外比较好的 VPS(虚拟服务器)的服务商。服务还算稳定,线路相对比较稳定,重点是,价格便宜。Vultr 在国外主要的节点城市都有自己的机房。日本、新加坡、阿姆斯特丹、巴黎、法兰克福、伦敦、美国东西海岸、多伦多、悉尼。 Vultr 最近有一个活动,第一次注册、付费超过 $25 的新用户,能获得 $50 的试用金,等于一台 1 Core/2G RAM 的服务器免费用 5 个月。牛逼。 对于做外贸、跨境电商的朋友,可以用 Vultr 配合 Cloudflare 免费版做图床,做 EDM 定时任务等等。或者其它做国外业务,希望自己需要一台可操控主机的,vultr 都适合你们。……

阅读全文

hexo 又成了技术流的玩具

其实写这篇文章,心情不太痛快。hexo 是我找了好久才确定下来,能用 markdown 写 blog 的系统。之前试过的如 jekyll 太复杂,而且定制化程度太低,不灵活。刚开始用 hexo 的时候发现它简直是尤物,轻便简洁,扩展性还不错,官方收录了很多 plugins,足够码农用了。 结果没过几年,hexo 也快成了技术流的玩具。 问题一。npm 依赖存在缺陷 首先是 "hexo@3.8.0" 某个依赖 "hexo-fs@0.2.2",后者依赖 "chokidar@1.2.7",而 chokidar 又依赖 "fsevents@1.1.3"。好了,最后这个 "fsevents@1.1.3" 是被 deprecated 的版本,包含原生库,已经不存在 binary 下载,从源码编译也会报错。错误的大意是跟 node 的版本不兼容。 下面我把这个关系链重新理一下。 graph LR; A["hexo@3.8.0"]-->B["hexo-fs@0.2.2"]; B-->C["chokidar@1.2.7"]; C-->D["fsevents@1.1.3"]; D-->E["(HELL)"]; 除了上面的问题以外,大量已经停更的 plugins 依赖的 "hexo-cli@1.0.3" 等旧库,也多对 "fsevents@1.1.3" 存在间接依赖。 用一句话来说后果,在 MacOS 下,用 hexo-cli new + npm i 的方式,根本安装不上 hexo。 问题二。插件的停更、老化 像上面提到的,停更的插件,其间接依赖的第三方库若是被废弃,插件本身也就不可用了。这是一种情况。 第二种情况,hexo 本身在发展,某些停更的第三方插件没有跟着做适配,结果是 hexo 的使用体验受到了影响。 第三种情况,最常见的。哪怕是官网列表中的插件,质量也是有高有低,对那些技术不灵光的用户实在麻烦。 解决方法 针对安装不上的问题。我也不知道怎么解决 :( 我用撞大运的办法,hexo-cli new 一个项目以后,手动修改 package.……

阅读全文

不过时的技术

最近两天被极客时间的新课刷群刷屏。刷屏的标题大多是“学了这么多年 Java,却连 singleton 都不会用”、“面试总被问高并发,你真的会么”这一类标题党。内容千篇一律是推荐极客时间打新的课程,《Java 并发编程实战》。 高并发哥又不是没做过,随手找了一下,发现陈皓在 2009 年的一篇文章就提到了正确的解法,以及背后的原因。《深入浅出单实例 SINGLETON 设计模式》。 文中给出几种功能上正确的 singleton 写法。 // version 1.4 public class Singleton { private volatile static Singleton singleton = null; private Singleton() {} public static Singleton getInstance() { if (singleton == null) { synchronized (Singleton.class) { if (singleton== null) { singleton= new Singleton(); } } } return singleton; } } 请留意私有变量的描述词 volatile,目的是不让编译器对指令进行重排序优化。 // version 1.5 public class Singleton { private volatile static Singleton singleton = new Singleton(); private Singleton() {} public static Singleton getInstance() { return singleton; } } 这是自动加载版本。每次加载类的时候,实例就生成了。所以加载类的过程可能会很慢(特别是有很多继承、引用的情况)。……

阅读全文

固态硬盘和优盘不是稳健的数据存储介质

说到固态硬盘(SSD)和优盘,恐怕很多人心里面有个潜在的印象,就是数据放在这里面,很安全,比在机械硬盘里面安全。最近两个朋友找我,帮找恢复数据的解决方案。两位都是数据放优盘或移动硬盘里面,遇到存储芯片故障。 其实长期不用的数据,放在固态硬盘里面,真的不一定是安全的。固态硬盘的存储原理是往浮栅晶体管上加/放电子,使晶体管的通电性能发生变化,形成通路/闭路,对应数字 1/0,从而达到记录数据的目的。这里就有个问题,浮栅中的电子会存在泄漏的情况,也就是说,记录的数据会丢失。通常,这种数据的丢失受电压(包括静电)、环境温度、以及存储时间的影响。希捷曾经有工程师在报告中讲,温度每上升 5 摄氏度,数据存储的时间就短一半。不通电不读写的情况下,保存在 Nand Flash(SSD、SD Card、TF Card、U Disk……)介质中的数据最多也就两年的存储寿命。最糟糕的情况是像移动硬盘、优盘这样的设备,插入电脑 USB 口的一瞬间,假如遇到静电,Nand Flash 芯片被瞬间高电压击穿,那不管当时环境温度多少、你有没有经常使用,你的数据都完蛋了。 记住,要保存数据,一定用机械硬盘。这是目前最稳妥的方法了。机械硬盘丢数据的风险,都是可以人为规避的。保存得当,存里面的数据,保存十年二十年没问题。不要再傻傻被 SSD、优盘骗了。等到数据都恢复不回来,再后悔。……

阅读全文

MacOS 下安装 flutter 遇到的一个依赖问题

最近在 MacOSX 上安装 flutter 也遇到一些问题。不是 MacOS Mojave 的问题,而是 flutter 依赖的一个开源库,它的依赖树出现版本不兼容问题。 运行 flutter doctor 出现如下提示。 [!] iOS toolchain - develop for iOS devices (Xcode 10.0) ✗ libimobiledevice and ideviceinstaller are not installed. To install, run: brew install –HEAD libimobiledevice brew install ideviceinstaller ✗ ios-deploy not installed. To install: brew install ios-deploy ✗ CocoaPods not installed. CocoaPods is used to retrieve the iOS platform side’s plugin code that responds to your plugin usage on the Dart side.……

阅读全文