路径依赖

傍晚,到楼下超市买零食和第二天的早餐。结账时,听见一位年轻人问老板娘有没有手机充值卡。充值卡?印象里,自从上了淘宝,就再也没有见过充值卡长什么样了。寻声望去——强壮而干练,直觉判断可能文化程度不高,一个勤劳而精明的年轻生意人。老板娘从柜台递给年轻人一张充值卡,他从裤兜里娴熟地掏出一张钞票,然后匆匆离去,步伐如飞。整个过程,似乎也没有自己想象的那般原始和低效。

回家的路上,我一直想:之所以自己认为线上充值更加理所当然,且有丝丝优越感,那是因为自己对整个流程都车轻路熟,并且不受地理位置的约束,一根网线,天下我有;年轻人之所以到超市购买充值卡,是因为他对这种面对面交易的每个细节都烂熟于心,勤快的双腿和灵活的头脑,这世上没有难做的生意。两条路径,都能到达目的地。

人们常说,条条道路通罗马。然而,对于个体,他往往只会不断重复的走其中的一条。这种路径依赖在生活中极其常见。在微博刚刚兴起那会儿,我极力推荐家里的妞儿使用微博替代新闻客户端。刚开始是抵触的,因为微博的确需要找对几个关注者以及习惯这种信息发布的方式后才能体会到它的与众不同。如今,此妞花在微博上的时间远超过其他App。京东才开始那两年,我推荐妞儿从淘宝分一部分败家资产到京东,妞儿一下子就急了,认为我是想收紧两根,如今,每天都京东快递、京东小哥的在我耳边念叨个不停,对于淘宝则是完全一个便宜货、二级市场的态度……真后悔当初的推荐。

路径依赖的确有助于我们在做选择的时候花更多的精力在目标身上,同时也注定了你思考和做事的局限性。妞儿依然严重依赖微博,因此她其实是错过了微信公众号以及知乎两个新的「与众不同」的信息汲取点的(当然,她发现了今日头条,并且认为那是「正规」的官方媒体);妞儿如今在淘宝和京东的败家分配难分伯仲,因此对她来说,京东商品品类的局限以及淘宝商品质量的参吃不齐都不是问题。

之所以产生路径依赖,往往与人们心理的惰性和安全感相关。对于程序员来说,随机的bug是最让人抓狂的。因为随机往往意味着难以重现,难以重现意味着troubleshooting的不是我之前走过的那个坑,也就意味着今晚TM的不能早点回家吃媳妇做的晚饭了,甚至连早饭也没有。对于架构师而言,如果一些新技术他未曾实践或应用,他会更倾向于所谓的「成熟可靠」的技术,也许他所谓的「成熟」已经是软件远古时代的轮子。所以,面对公司里的「老油条」以及创业路上的大佬,你不用恐慌,他们只是更加熟悉已有的游戏规则,你不要按照常理出牌或者在一个小的点上逐步开始新的的玩法,他们往往会被你吓一跳。

不同的路径依赖,影响着在我们眼里什么是奇葩,什么是傻x,什么是对,什么是错。很多路径依赖会以「经验」的方式祸害下一代。我并不是说经验无用,而是需要警惕这种戴着路径依赖伪装的伪经验。如果有人这段时间跟你说:现在理财要投身天朝股市,你看xx已经赚了几十万了;你的车险就在王大姐那买就行了,李哥的车险在那买就是便宜又省心;以后你有孩子孩子了,记得要买xx品牌的奶粉,吃了两个月长的跟一岁的婴儿一样……也许我不用举太多的例子,很多这样的路径依赖经验最后演化的结果就是「以讹传讹」。正如今日开始的高考,绝大部分考生其实不知道何为「大学」,但是他们已经被驱赶到了这条路径上——这条路径很有可能并不是他们自己选择的,甚至他们都不知道这条路径到底是什么鬼。

在「小道消息」被关前,看到Fenng的一个观点:人其实一直排斥自我的进步。因为进步总是痛苦和相对困难的。路径依赖很多时候在进步过程中扮演者着那个带着温柔乡的绊脚石——难以察觉,甚至一直认为理所当然,然而,某日,我是说如果有机会的话,走过那块绊脚石,哈,原来昨日的自己就是今晚超市的年轻人。别急着庆祝——另一位超市的年轻人已经在你未来的路上候着你了。

golang中的错误处理模式

年前拜读了Rob Pike的Errors are values,不禁感叹——原来错误可以这样处理。这里简单做一个笔记。

模式1:闭包记录异常

这种方式适用于多次相同类型调用的错误处理。缺点就是,每个类似的地方都需要引入一个闭包函数,显得冗余重复。

模式2:组合error struct

代码比第一种方式更加干净。但是与第一种方式有一样的问题,就是无法具体的知道是在哪个位置发生的错误以及错误的具体信息。

模式3:error转化为panic

来自知乎唐生的回答:

这种方式的通用性较好。但是把error主动转化为panic会导致goroutine的stack unwind。这会带来一定的系统开销,甚至是系统性能抖动。

参考:

你应该记住的一个UTF-8字符「EF BF BD」

utf-8是一种变长(1 byte ~ 6 bytes)的unicode字符集编码方案。所谓编码方案即讲字符集到码点(code point)的映射方式。

在众多的utf-8码点值中,除了ascii,你还应该记住「EF BF BD」,因为它是很多编程语言以及库中的备胎,即无效的码点值在编码的时候会默认用这个码点值进行替换,即utf-8中的超级「备胎」(REPLACEMENT CHARACTER)。

为什么会有无效的码点值?

UTF-8 Code Point

从上图可以知道,utf-8编码 并非连续的 。很多人会忽略这个细节。

什么时候会遇到无效的utf-8码点?

当你试图把一个无效的码点值作为utf-8码点处理时,就会产生无效的码点。此时,无效的码点会被替换为「EF BF BD」,然后进行后续处理,以避免无效码点可能引起的异常。很多语言对这种处理是 自动进行 的,比如golang:

为什么要记住这个码点

在「字符集敏感」的环境中,如果你的数据中出现了「EF BF BD」就应该警惕了,因为你传输的数据中途很可能经过了自动替换,收到的数据未必是原始的数据。这对于你排查一些奇怪的数据交换不一致问题是很有用的,很多时候,可能是你的最后一颗救命稻草。

例如,使用utf-8编码的xml文档进行数据交换,如果看见了「�」,毫无疑问数据源有非法码点值。网页中出现了「�」,那么肯定是html文档的编码不是合规的utf-8编码文档。文本编辑器中出现了「�」,那一定是你打开这个文档的姿势不对——又选错编码了。总之,当你看见超级备胎「�」的时候,不要觉得大事不妙,不要像遇到一般乱码那样惊慌失措,你应该轻轻弹一下鼠标上的灰尘,将之打回原形。


因为aws的账单,才意识到自己的vps已经很久没有折腾了,博客也已经长草,应该说已经长成灌木丛了。

这才意识到自己已经回成都快9个月了。

有人说,时间是把杀猪刀。这很公平。但是,即使哪天挨上了这杀猪刀,也希望自己是头优雅的猪。

而此时,2015已经过去1/4.