浮云计算

杂思丨近日状况

Thu, 11 Jan 2024 00:16:25 +0800

最近 James 瞄了一眼我博客以后，
点评了一下：“某个博主很久没更新了。”
我看着 2023 年仅更新的 3 篇文章，
也只能直面拥抱自己找不到借口的懒惰。

（一）

去年没看几本书，微信读书说我读的最快的是《道诡异仙》，
这本书给我的情感冲击无异于中二时读到的《佣兵天下》。
佣兵属于是年少轻狂的少年遇到了构建完整的西幻世界，
道诡异仙则是属于这个混沌时代的顶尖发疯文学。

最近一个月经受着各种年终盘点的轰炸，
似乎手机上只要是个像样的应用，
年底就会分一部分产研来做年度回顾的项目。
很多习惯就是在奇怪的默契中发展成习俗。

我个人并不喜欢把文化中新的习俗称之为“创新”。
比如去年朋友圈火过一天的闻会军，
他有趣的点在于给日常生活中插入不和谐的部分，
本质上与“脑残游戏”中乐趣来自于醒不来的人是一样的。
不过我也不算老几，我也发了闻神状态玩得很开心。

（二）

人总是会陷入或这或那的矛盾中。
我前阵子煞有介事地写了《为什么我讨厌吸烟》，
几年过后，今天的我突然发现自己并不讨厌吸烟的人。
从好的方面而言，烟草在社会层面贡献了收入、岗位，提供了消费、娱乐，

从坏的方面来说，吸烟的人拥有更短的平均寿命，降低了养老压力，

从吸烟本身而言，这个行为不致幻、影响较小、可以被自制。
只要我关心的人不吸烟，吸烟的人看起来也挺友善的。

写到这里，我一惊，不禁想到了以前跟我爸的一次经典对话。
我问我爸：“你对同性恋是怎么看法？”
我爸：“噢，现代社会很正常的存在啊，他们也都是正常人blabla”
我：“假如我是同性恋呢？”
我爸：“啊你不能是同性恋。”

利益相关原则是成熟社会人必须学会的法则，
但这也是我心里偷偷伤心的“大人已经不如小朋友可爱”的一环。

（三）

之前跟 Mia 郁闷吐槽，我感慨最近时常感到自己相当油腻、一点也不可爱了。
Mia 安慰我，说：“你这个年纪有一些油腻是很正常的，男人中年都这样。”
我：…………
这种伤春悲秋被打蛇随棍上结果无话可说的体验令人接话不能。

好在我后来体重轻了几斤，并且遇到了《大地雷公》这首歌，心态也可以很快转变过来了。
俗话说人知道自己的愚蠢就不愚蠢，那人知道自己的油腻大概也不油腻了。
勇敢的人享受生活，无知的人一直快乐。

平生不修善果，只爱杀人放火。忽地顿开金绳，这里扯断玉锁。咦！钱塘江上潮信来，今日方知我是我。
—— 偈语，鲁智深圆寂前

有时觉得做男生还挺简单的，
不当成功人士就没有太多的社会压力，
只要不肥多运动、谦虚少吹牛、自律爱学习、干净且克制就可以一直像一个少年。
而成为一个少年本身就是最快乐的事情。

（四）

2024年是我近几年最喜欢的一年。
2024这个数字本身就很妙，
是2的倍数、4的倍数、7的倍数、8的倍数，在算错的情况下还可以是3的倍数、6的倍数。
是龙年，也是奥运年，跟2012末日年比是两倍末日，跟印象深刻的2008相比会有三倍回忆，
而且在这一年所有人的出生年份加上年龄恰好也等于2024。
总而言之，2024就是我很喜欢的一年。

就像调电视音量一样，25是合适的音量，24也是合适的音量，但是23肯定不是，至少得下调到21或者20。
每个人都会有若即若离的强迫症。

强迫症对于程序员，就像是洁癖对于医生一样，
是一个略苦恼但对职业发展大有脾益的毛病。
除了在《我的一点强迫症》里标记的正确使用全半角、文本文件要换行、正确使用的地得，
近几年我特别在意的问题还包括“优惠券、阈值的正确发音”、“别在接口里面拼错单词”以及“说鸡就不说吧文明你我他”。

没有波动的生活是相对乏味的人生，并不好玩。

（五）

最近大部分时间都献给了工作，
在 Opus 工作的这几个月是我近几年最兴奋的时光：
队友们三头六臂、增长上披荆斩棘、战略侧谨慎乐观、开发时百废待兴。
想说的话有很多，更详细的感言我会等到蜜月期过了以后，好好思考以后再单独行文。

关于工作我感触最深的一点，倒是学长常说的那句个人奋斗与历史进程。
在以数十年为尺度的职业生涯中，很多早早躺下的人与“奋斗”这两个词已经无缘了，
许多人快乐地浪费着自己的才华，在我看来只是有点惋惜。
而在剩下的事业中，“历史的进程”或者说“周期”是一个跨不过去的门槛。
再优秀的个体、再灿烂的十年、再好的一代年轻人，可能都会耗在康波周期的阶段中。
不过这点辩证难度，对中国人来说还是太简单了：
就像爬山一样，在平原期好好休息享受风景，但爬坡时要目标坚定大力攀登，这样就能享受顶峰的风景。
所谓“逆风蓄力，顺风起势”。

希望我能把自己这一点才能，转换成旺盛的火苗，投入 Opus 的这把大火里。

（六）

最近工作上还有一个很好玩的感触，来自于讲英文。
Yes, speak English。
虽说是创业团队，但是我们同事来自各个国家和地区，
大家都用不同的乡音讲着同样的英语。

热知识：两个朋友用英语沟通时，更吃力的其实是英语讲得更好的那位。
由于他讲的英语更标准，所以对面的朋友理解起来也更简单，
但对面朋友脑子中不会记得语态词性，更多还是得靠听来理解。
偷偷感谢一下我的同事们，我的英语顺畅沟通完全得益于他们强大的听力。

除了语言能力外，英语相比于中文的表意是更直接的，
对我个人感觉尤其明显。
比如在给技术观点时，我用中文默认会委婉表达“那样可能更好”，
但用英文我就会更直白地说“No, I don’t recommend to do this.”
更直接的表意会带来更清晰的观点，
这确实也更接近奈飞文化中的“成年人文化”。

（七）

在工作之外的时间里，最近还对运动比较着迷，
不过鉴于运动是结果比过程重要，这个就等有结果了再来分享一二吧 :)

过程与结果之争永远是一个迷人的话题，
不论是Mia&Sebastian的结局，还是Joker&Batman的正义之争，甚至是封控&放开的论战，
都是可以认真感受的品评。

人最宝贵的所有就是时间，时间也会平等地浪费在每一个人身上。
从这一点而言，人注定是要当一个长期主义者的。

当然啦，那又是另一篇文章了，希望以后的文章，比现在的更有营养也更可爱 :)

（完）

骑行一年记

Mon, 16 Oct 2023 20:09:04 +0800

过去的一年来，
我骑行了 1000km+ 的距离。
骑行是孤独的，
但孤独也是美丽的。

契机

以前上中学时，我有一阵总是周末骑到隔壁镇找女朋友玩，
记忆里的 5km 是尘土飞扬、野花丛生、时间飞逝的旅程。

后来在大学的小树林单车店也买了车，
载室友郁翔的时间比载女朋友的时间多多了。
但是那个年代车多锁差，
大学四年我连着丢了四辆车。
后来回校跟学弟们感慨“校园里单车真容易丢”，
从他们疑惑的眼神里，
我看出了时代的参差。
这就是共享单车——新时代经济对旧时代文化的彻底冲击。
当然了，丢车不算什么好的旧时代文化，一点也不值得怀念。

大学毕业以后，我就安心地当一个阳光宅男，
靠着高代谢维持着高热量的生活，再也没有认真运动过。
—— 直到 22 年幸福的封控生活把我抬到了 80kg。

或许给我运动人格的转变找到了合适的理由？
这么想着的我，去迪卡侬逛了一圈，
在网上下单了一辆公路车：迪卡侬 RC100。

后勤

骑行跟跑步类似，是一项运动（此句为废话）。
骑行与跑步不同，需要更多的后勤工作。

骑行最重要的是——要有一辆自行车。
市面上常见的有两种，公路车和山地车。
公路车一般是弯把细胎，适合铺装路面的骑行，
对于城市通勤、晨起夜骑咖啡骑的场景都是完美适配。
山地车一般是直把粗胎，避震效果良好，适合路况复杂的骑行，
对于山路草地、负重骑行的场景是非常适合的。
1000多元可以买到带变速的各方面都不错的自行车，
但假如按三分钟热度来算，每分钟要几百块，不便宜了。
于是我在下决心买车的前一个月，骑了30天共享单车：
得想自己证明一个决定是可坚持的。

除了车以外，最重要的设备是头盔。
头盔这种东西跟寿险某种程度上很像：
你并不希望它发挥作用，
但买的时候总想算一下“投资回报率”。
在这一年的骑行旅途中，
除了压制我爆炸的头发，
我的头盔没有发挥任何实际作用。
这令我十分欣慰。

剩下的后勤准备大致分为三个类别：防护、数据、消耗品。

防护用品包括手套、速干衣、骑行裤、护膝、长袜，
这些零散的外设是我随着骑行旅途逐个获取的。
因为在实际的骑行中，我实际感受到了手疼、汗多、蛋疼、摔跤、脚滑。
每个人骑行的实际体感都是不一样的，
要么学会忍受，要么改进后勤。

数据上的准备，包括体重秤、手环、码表、心率计、踏频计等。
最令我兴奋的是体重秤：“我都开始骑行了，你至少给我轻几斤吧？”
于是体重秤很诚实的告诉我：“你体重没变。”
（骑行确实不能减重，少吃才能减重）
数据是最诚实的伙伴，
没有数据前，我只能感受到自己是个菜鸡，
有了数据后，我就能量化地看到自己有多菜。

消耗品则包括且不限于内胎、香蕉、运动饮料等等。
在骑行苏州的过程中，我尝试统计了一下自己的消耗：
大概是每百公里8L康师傅冰红茶。

算上自行车，这一年陆陆续续花在骑行上的钱大概是5千多。
往年给手游老婆们氪的金，今年基本氪给自己了。

骑行圈跟装机圈一样，也有攀比设备的价格党们。
但骑行也像跑步一样，最大的瓶颈永远是骑手本人。

路线

在后勤工作还没做到位的情况下，
我就迫不及待地开始骑行了。
——甚至连网购的车还没到，
我就先戴上头盔，
骑上共享单车，
沿着之前查好的路线往返于公司和家之间。

当时我常骑的路线是人民广场（黄浦区）到第六人民医院（徐汇区），
单程10公里，红绿灯30余个（……），全程耗时约50分钟，不计停时约30分钟。

从我个人感受来说，
每天20公里是一个非常适合骑行的距离：
有一定的量，但不累，不用为此单独换衣服，如果下雨或是正装见客户就可以先不骑；
通勤时间可控，比地铁通勤也就多花几十分钟，但带来的是能迎着阳光上班的体验。

上班通勤路线最大的挑战是路况。
市区通勤一般等价于被外卖小哥抢道、被违规停车挡道、被路边行人插道。
核心就是记住一句话：谁弱谁有理，但谁弱谁先死。
不论如何，希望大家行走、骑行、驾车都要注意安全。

周末骑行的路线则有很多选择了。
我最喜欢的两条线路是龙腾大道往返和黄浦江绕圈。

龙腾大道往返，路线是从龙美术馆到徐浦大桥，
往返一圈约14公里，是骑行团们晨骑喜欢的去处。
早上5点，徐汇滨江湖面辉映射出浅金色的阳光，
清晨的雾气打在了每一个努力爬坡的骑手腿上，
晨骑团在路口转弯发出的整齐花鼓声也是这幅画的一份子。

黄浦江绕圈，则是一个更加休闲的路线。
上海沿着黄浦江摆放了多个渡口，
从三林路渡口过浦东，一直到东昌路渡口归浦西是我喜欢的路线。
假若是清晨出发，则一路上人烟稀少，偶有骑行俱乐部共行一路；
某次在傍晚出发，突然倾盆大雨，暴雨中躲在南浦大桥发光的肚皮下躲雨，
雨滴随着耳机里的音乐让整个世界都混进了同一个节奏。

如此这般，非日常的体验会让日常格外美丽。

体验

骑行的一年来，除去学修车、减了脂的这种副作用，
我最开心的一点是找到了“本命运动”：
假如英灵殿里有我，那我大概离 Rider 这个职介更近了。

生命在于体验，体验产生回忆，回忆是快乐的，快乐则是生命的美好未来。

骑行路过七宝时，阳光明媚的天气突然一道黑影掠过。
我愣了几秒以后才反应过来：一架飞机的影子恰巧掠过了我的肩上。
踩回闵行的路上，红灯路口一个反着坐在妈妈摩托上的小朋友好奇地看着我，
我虽然捂得严严实实，但还是努力对他做了个笑容，比了个赞，希望他快高长大。
在黄浦江绕圈的某天早上，也是突发大雨，我和陌生的骑手朋友躲在屋檐下聊了半小时，
共骑了半程，互换了微信，他邀我入骑行群，认识了更多的朋友。
从苏州归来的我，在省道边的一个休息站疲惫地停了下来，
服务员小妹妹则是特别贴心地给我拿了小板凳，示意我坐着休息一会儿。

总的来说，骑行就是这样一个普通的运动：

需要投入，但是不必攀比。
无法减肥，但是上手简单。
旅程孤独，但是世界很大。

在后续的时间里，
我计划尝试 200km 的单日沪杭挑战，
有可能的话以后也试试西藏骑行、环台湾岛、世界各处的骑行。
不过话说回来，现在还早，
先从通勤骑起来吧~

（完）

我的妈妈苏琳

Thu, 17 Aug 2023 22:06:52 +0800

我的妈妈叫苏琳。
她还有一个弟弟和一个妹妹，
名字分别是“农”和“静”，
这几个名字都铿锵响亮，
大概也许都是外公取的吧。

我时常会跟我妈聊起她小时候的事情。
在断断续续的记忆碎片里，
她从民国前讲到了我小时候，
我知道了我外公的爷爷以前就在湖南经商，
也听到了生于 1968 年的妈妈是如何津津有味地过着普通的生活。

湖南的天气与上海没有太大的差别。
去年上海下了一阵雪，
我妈在语音电话中感慨：
她在像我这么大时（指30岁），
经历了携母带子在大雪天乘火车南下，
与搬家先行出发的我爸在广东汇合，
最终二人在广东定居，
如此教书三十年。

“时间过起来可真快啊！”
苏琳老师如此感慨。
而后，她又对我补充了一句：
“感觉你嗖一下就长大了。”

如今我儿时记忆已逐渐远去，
但父母小时候讲的故事总是难以忘怀。
其中一幕更是铭记于心：
小学做完作业后，我妈会捧着一本《岳飞演义》给我念上一段，
这种可以边听边问的“互动式评书”成了我翘首以盼的期待。
在那之后，虽然我再也没重读过这本书，
但岳母、牛皋、金兀术、岳云等形象也随着妈妈的话刻在了我的脑海中。

前阵子我想起这桩往事，
又找我妈求证：“为什么我就记得你给我念了一本书？”
苏琳老师无奈地告诉我了真相：
那时因为我识字不多，
她又嫌注音版的儿童读本愚笨，
便尝试给我念了一段，
没想到一年就是大半年。
后来看我能囫囵吞枣地自己读，
就让我自力更生去读了。

苏琳老师全权负责着她儿子的教育，
这也是她颇为自豪、颇有成就感的事情。
工作以后，我也体会到类似的感受：
作为程序员的我全权负责着家里面的计算机与网络，
这也让我颇为自豪、颇有成就感。

苏琳老师教的是初中历史。
在学校教学任务忙的时候，
也曾经客串过语文、英语或地理老师。
后来在学校的安排下，
她每年都兼任着历史课组长和毕业班老师的工作。
我也才知道，
并不是所有老师都是一届教三年，
稀有的好老师原来是一年教一届。

除了业务能力优秀，苏琳老师还很受学生喜欢。
不仅每年都会被学生票选为最受欢迎老师，
出门逛超市的苏琳老师也会遭遇毕业十几年的学生热情相认。
今年的毕业班上，
有学生听闻了她要退休的传言，
非常震惊地找苏琳老师求证，
她却逗学生：“我今年还没退休呢，你毕业以后记得回学校看老师哦！”

苏琳老师也是最早的一批网民。
她在论坛里的名字叫“青夏”，
有着许多认识了十几年的网友。
最开始我好奇地问她：“这个论坛是做什么的？”
“是网友们交换种子的。”
我大为震惊：“交换种子？！？”

是的，青夏是本地园艺论坛的一员。
她在家里收拾了一片种菜的天地。
这一片地里种了黄瓜、丝瓜、南瓜，
那一片地里种了芒果、火龙果、圣女果，
而在拐角处的那几十个花盆里，
分别是金银花、满天星、七彩凤、旱金莲等五彩缤纷的花朵们…

园艺论坛偶尔会举办线下花友会。
青夏也带着花种子从线上蹦到了线下，
聚会地点一般是本地的公园，
花友们还会带水果、特产，
还有外地驱车赶来的花友参与这场盛会。
从花友会回来的青夏不仅会带着新鲜种子，
也会带着新认识的朋友新鲜事讲给她儿子听。

后来我每次看到“中国人自带种菜基因”，
总有些疑惑与期待。
既觉得这句话不像是编的，
又不知道我的那部分基因何时觉醒。

我外公退休后也沉迷过钓鱼种菜，
沉迷时，每天早上5点就要出门锄地，
后来身体不好也就在家享享清福。
我妈便挑选了些适合阳台种的菜拿给外公，
让他可以在小的花园里培育大的世界。

身边的人也都知道苏琳老师是植物大师。
以前出门徒步时，
经常有朋友问她：“苏老师，这是什么花？这是什么树？这是什么植物？”
我也经常这么问她，
她同样的问题答了很多遍，
看我是真的不懂而且没记性，
便真诚地教我：“你可以下载一个百度，首页就有拍照识图的功能，很好用的。”
如今我看到路边的花花草草，
好奇心就有点骚动。

就像你能从文字里读出来的一样，
苏琳老师有着盛开的好奇心与求知欲。
比如她一直会纠结汉字的正确读音，
遇到生僻字一定会现场查出正确读法，
也会纠正我爸和我的错误读音，
即使我们都不用做语文卷子了。
这或许也很大程度影响了我，
以及我听到优惠“卷”或者“阀”值时的毛躁程度。

我妈今年满55岁要退休了。
不论按阴历生日七月初四，
还是按身份证生日8月22号来算，
这都是她过的最后一个暑假了。
她也终于下定了决心，
拉上我爸去西藏来了一次毕业旅行。

一生里我只见到几次苏琳女士有真正想去的地方。
2008年，她差点报上了离家去四川的支教团。
但子女在，难远游。
后来十几年里，她一直期待着去西藏，
这次也总算是没有严重高反地顺利旅行了。
我为她感到高兴。

从我出生起，妈妈就是妈妈的样子了。
但我总觉得，作为苏琳老师，妈妈也有着非常的潇洒一面。

最了解我妈妈的人是我爸，
他对我妈妈的评价是：
你妈妈是有内美的人。
这句话与屈原自评惊人的一致：
纷吾既有此内美兮，又重之以修能。

以前在网上搜索“苏琳”，
可以搜到第一只赴美的大熊猫就名为苏琳。
希望以后，苏琳老师也可以随着本文，
以一个潇洒的形象活在互联网的某个角落里，
就像青夏曾经也活跃在某个花友论坛里。
她退休的日子，
也肯定像她的学生们和受她影响的人们一样，
把普通的生活里过得津津有味。

这就是我的妈妈，
苏琳老师。

在北极九章工作的这一年

Tue, 28 Feb 2023 22:09:15 +0800

与宇轩吃饭时，
突然意识到我已经来了北极一年整了。
在再惠工作一年时，
我写下了《我的工作》，
今天或许是个合适的时间来记点什么。

引言

致远刚入职北极的时候，
她经常与我感慨：“真的非常喜欢咱们北极，太符合我的口味了！”
我总会这么安慰她：“前半年总是新鲜的，长情才是对公司最好的告白。”

同处新鲜期的我，
去年经常有给工作写点什么的冲动，
但也被我自己摁下来了。

一年至今，热情稍退，热枕依然。
今日再回头，
可以从创业的心态、变化的环境、持续的思考这几个角度分享一些心得跟体会吧。

创业的心态

又从初创阶段开始做起，
终于可以有底气地说：
我确实很喜欢在创业型公司工作。

创新

由于我司做的是行业里新的方向，
所以很多功能实现、产品体验都要摸着别人过河。
更有甚者，作为先发者还会被别人摸着过河，
当然了，最后还是得比拼产品功能体验。

2022年我参与的好几个项目，
都是全球行业内只能找到寥寥几个竞品，
甚至还有首创的功能。
后来客户赞赏产品的时候，
我就像看着小孩考上了复旦一样开心。

但是也有不少苦逼的时候，
我们也有许多胎死腹中的需求文档、
半路夭折的技术实现、
市场验证下急需优化的产品功能。

创业做创新，
就像用有限的精力和资源，
加上无限的智慧和勇气，
去面对超限的困难和未知。

充实

在工作了几年以后，
我的同龄人们基本对自己想要什么都很清楚。
想躺平的同学回了老家，
想稳定的同学进了大厂（前几年进的），
而我，有梦饮水饱。

人还是要做事的，不做事不行。
—— 我奶奶

在北极做事情突出一个充实。
我们的工作方式是双月OKR + 单周迭代，
没有不写代码的 Tech Lead，
也没见到有不爱写代码的 Tech Lead。

刚参加工作的我曾经受到过 Work Hard, Play Hard. 的文化影响，
今天确实也沉浸在了这种开心充实的状态中。

朋友们讨论何时提前退休，
而发出“希望一直开心的工作下去”的我，
就像一个可爱的异类一样，
跟大家开开心心地鬼混在了一起。

我一向认为工作是生活的一部分。
因为喜欢，所以充实是幸福。

同道

俗话叫“不怕别人聪明，也不怕别人努力，就怕别人比你聪明还比你努力。”
（另一个现实版本是有钱、帅气）

跟前端周五分好的技术调研，
周一她就说“周末没啥事，我这部分做差不多了…”
能与同样在业余时间学习技术的人当队友，
真的是十分幸福。

队友们在技术上也有相对一致的好品味，
像保持新版本依赖、单元测试覆盖率、清晰的提交历史与严苛的代码风格，
这些最佳实践也融入了大家的编码日常，
这让有一定技术洁癖的我感觉十分舒服。

这一年也有几个我喜欢的队友离开了，
Andrew 去了美国，
Eva 追着林俊杰跑，
芷依在溜她的柴犬。
这一年也与更多志同道合的朋友成为了伙伴，
为了避免厚此薄彼，就不额外点名了 :)

👆 神奇的是，许愿生效了，一个月内确实赐予了

不过这也是生活美丽的地方：
没人能预测与谁会在转角再相遇。

变化的环境

刚毕业的时候，
听老板讲大环境趋势，
听前辈讲行业变革，
总是有种隔靴搔痒的感觉。
但如今视野更开阔以后，
确实对“个人的奋斗与历史的车轮”有了更加切身的体会。

经济形势

当今世界影响最大的进程是中美事实上的脱钩，
背后是中美各自面对的经济难题。

一方面影响是 UVCA 时代下的不确定性主题。
包括个人对未来搞钱形式的判断不一，
导致人才去向的不一；
也包括资本从收益率转向盈利率，
导致整体融资投资环境的风口变化。

另一方面影响则是企业跟国际政治的绑定更紧。
不少外资企业逐步撤出了中国，
国内对专精特新、信创产业等有着非常高的需求。
因为我司是自研核心专利的信创公司，
这一年给很多客户讲解产品以后，
不仅功能本身收到了很好的反馈，
而且作为扎实做产品的信创公司也受到了很好的评价。

以前我并没接触过多少500强级别的大客户，
但去年很快进入了状态，
实在是感谢带着我跑客户的牛逼销售伙伴们。

行业趋势

数据行业最大的趋势，是大家都在极力做低门槛。

就像从刀塔、到英雄联盟、到王者荣耀，
操作门槛在降低，
但是玩家数目极大上升，
影响了更多人的娱乐方式。

数据分析最早只有懂 SQL 或者懂 Python 的人才能做。
后来出现了 tableau、帆软这样的拖拽式 BI，
了解数据格式、数据关系的人就可以做报表了。
而北极做的是语义化的数据分析，
首页就是一个聊天框，会聊天就可以分析数据了。

最近 ChatGPT 又火了一轮，
这次更加出圈，
倒是把行业趋势大大往前推了一把。
以前可能还要教育市场什么是“语义化增强型分析”，
现在经常会遇到很懂行可以深入交流的客户。

工作文化

文化是时代跟水土的产物。
对于工作亦然。

工作推进要讲文化。

我在北极开始工作的时候，
给自己定下了一个规矩：
“不能有思维定势，不能有路径依赖。”
具体来说，就是我不能说任何类似
“我在前司是全线上k8s的”
或是“我们以前是后端功能保持向前兼容”这样的话。
一方面涉嫌在现女友面前夸前女友：居心不良，
另一方面也是不能依葫芦画瓢：要实事求是。
所以在推进技术决策、需求组织时，
我更愿意采用预研、讨论、共识、推进的节奏，
相比于直接推进“怎么做”，
让大家了解“为什么”是更重要的。

团队沟通要讲文化。

不同人因为不同背景、不同角度会有不同方式。
我一直不适应看大家吵架，
假如开会时有人观点激烈冲突，
我总会想建议大家先确定共识，
然后私下温和（也不一定温和）地讨论。
但这一年我时常在会议中发现，
几个队友吵着吵着也达成了一个共识，
并在这个过程中充分表达了自己的观点，
到了中午还一起勾肩搭背去吃盖浇饭……
确实，团队里不同人适应的沟通风格也是不一样的。

也要适应时代变化。

每个时代会有自己的“政治正确”。
在如今的工作文化里，
“要工资，更要发展”是比“吃亏就是占便宜”更能公开宣扬的理论，
“适量工作，恰当躺平”也比“努力，奋斗”有着更主流的思潮位。
所以在这个背景下，“结果导向”、“人情味”、“严于律己”是做好事情的最基础要求。

时代变化伴随着文化变化，
文化变化要求组织形式的变化。

虽然写的有点虚无缥缈了，
但这确实是最近我对世界的认知，
看起来我确实践行了自己的格言：
“唯心地思考，唯物地生活。”

持续的思考

我对这个小标题并不满意，
看起来“的”、“地”似乎写错了，
但我想讲的确实是一个持续的思考。

一直以来我都有一个很大的恐惧，
就是担心自己变成1+N年工作经验的人：
只有工作的第一年在学习思考，
后面的N年都在机械重复。

而我目前的工作也对我提出了新的挑战：
“避免做一个战术上勤奋、战略上懒惰的人。”

就比如我们做产品，
看似有非常多事情可以做，
有无数的功能等待去完成。
但不加以深入思考，
就会陷入做起来很忙，
但实际上对客户不关键的陷阱中。

“人云亦云”、“顺水推舟”、“三不原则”（不主动不抗拒不负责）
在我眼里都是“战术上勤奋、战略上懒惰”的 bad case。

不论如何，人还是要多多学习一个的。

结语

脚踩西瓜皮，写到哪里是哪里。
一连写到这，我也忘了要说啥。
那最后以一个小趣事结尾吧。

一年前的“北极九章”并不叫“北极九章”，
当时的名字还叫“北极数据”。
2022年，这家名为“北极数据”的公司已经创立了三年有余，
但醉心于产品研发的创始人居然忘了申请商标，
于是只能顺势改名为“北极九章”完成一个品牌的升级。

“北极九章”组成于“冰山理论”的“北极”跟“九章算术”的九章。
不过我个人倒是认为，
可能名字也会来源于创始人Allen特别喜欢的🐻这个动物，
以及“楚辞九章”这么一个美好的语言文学文本。

最后，希望大家也都能像土豆一样，
在新的一年对自己发出“纷吾既有此内美兮，又重之以修能”的楚辞式感慨。

（完）

杂思丨屁股决定脑袋

Mon, 26 Sep 2022 20:00:36 +0800

人贵在连续性，
即使前言不搭后语，
我的心中一直这么想道。
但真到了发现与旧日的我思考异化的那天，
自己不仅也是有点感慨的。

（一）招聘标准

我经常与朋友分享招聘中的趣事，
其中有一个我以前很喜欢讲。

当时公司面试后端工程师，
采用的是多轮面试与一票否决制的招聘制度，
我经常担任第一轮的面试官。
某一天，我与同事内推的归国小哥聊完了，
很开心地与队友们说：“这个候选人不错，可能会队友+1了！”
但一小时后，第二轮的面试官出来，面露难色：“这个候选人不太行啊，我给pass了。”
把候选人送走以后，大家问面试官为何，他复述了如此一个场景：

在聊完了具体的计算机网络、数据库、服务器等话题以后，
面试官接着问：“你能讲讲你在上家公司做的最成功的一件事是什么吗？”
候选人非常开心地接过了话：
“当然可以！我上家公司是做衣服批发的，当时公司的物流成本居高不下，因为衣物占用了很多体积空间。
后来我发现了可以用上一种真空包装，在减少衣物体积的同时，不损失衣物质量！
最终给公司节省了上百万美元的费用呢！”

每次讲完这个面试故事以后，
我的听众朋友们都会陷入沉默，
然后问道：“那这个跟后端工程师有什么关系呢？”
我们便一起哄笑：“对啊，这就是不合适的面试策略。”

但不知何时起，
我心中常常浮现出讲完故事后跟着一起哄笑的场景，
这个场景散发出的回忆刺微微地痛着我。

后来的我再也没跟新朋友们聊起过这个故事，
当面试官的时候也更有耐心。
过去作为纯技术面试官，会首先要求候选人写代码能力要好。
但如今作为面试官，我更看重候选人能解决事情的能力。
假如他给出了一个不切题的答案，
我会多问一句：“能不能分享一下这件事情对你职业上的影响呢？”

当我们聊到招聘标准时，
招聘队友，确实跟招聘队员，会有着不同的看法。

（二）公司制度

今年我想得很多的一个话题就是远程工作。
一番思考以后，我发现了自己是一个彻底的双标狗：
“作为老板，我不愿意推行灵活远程办公制度。
作为员工，我希望公司推行灵活远程办公制度。”

简单的逻辑思考如下：

人只有自制力强，远程办公才不会损失效率。假如自制力差，远程办公就会损失效率。
除非招聘环节中特别考核，否则员工们的自制力会呈正态分布。
自制力高与生产力高，不是强相关的属性。

所以这个问题就得出了这么一个结论：
要推行远程办公，要么依赖员工自制力，要么就得接受效率损失。
而我们很清楚，工作中的二选一往往答案都是全选：
推行远程办公，既要依赖员工自制力，也得接受一定的效率损失。

而像这种问题，与
“以防纸巾经常拿光，纸巾畅拿政策改为每人每周一包政策”、
“年假无限，但因为真的有人请了连续一个月假期，而改为法定的每年五天”一样，
它们不仅是人性的问题，还是利润最大化的问题、温度分割线的问题。

公司制度，可能最终都会回落到中庸但正确的公约数。

（三）奋斗态度

有的时候相比于个人的思想转变，
群体的言论转变更是耐人寻味。

关于工作本身的社会舆论一直在变化，
从以前的“支持宣扬狼性文化”到现在的“警惕提防996资本吸血”也不过数年时间。
但随着舆论两边踏浪的大众，
会有多少人真正思考过自己的事业、阶段、坚持、独特、苦难与成就呢？
个中之人，能坚持自己独立思考并走一条不后悔的路也是少之又少。
——《我言、我知、我行》

在躺平论引领风潮后，
如今越来越频繁地看到网上出现了更多不一样的声音：
“说着躺平，那楼主你躺平了吗？”
“996 真的是福报了，至少你还有工作。”
这种话里话外透出的悲观，
可以看得到大势影响下的集体性思潮。
这或许就是一种循环吧。

另一个好玩的事，是我现在很难开口劝别人要努力工作了。
在我刚工作的时候，我一边开心，一边在2018年的OKR里写下“工作的奖赏就是工作本身”。
到了今天，我被视为“有能力的前辈”，我也尝到了“工作的奖赏就是工作本身”的美妙滋味，
但我却无法红着脸说出这样的话语。

少年劝进，是为活力。
中年劝进，是为油腻。

（四）写代码

甚至写代码也会受到思考角度的影响。

在无数网站的个人签名中，
我最喜欢自己在 GitHub 上留下的介绍：

Lirian Su:
This is a vimer, a pythonista, a gopher
and a business man on the way.
Code for life rather than code for work.
Wubba lubba dub dub.

但随着能力与责任范围的变大，
产品、运营、业务也摆在了我的面前：
事业的成功需要领域的手段，技术也是其中之一。
于是“万般皆下品，唯有写代码”的思维开始松动，
逐渐走向了“工程师是解决问题的人”。

如今在团队中，
假如瓶颈是技术，我就做技术；
假如瓶颈在产品，我便优化产品；
假如瓶颈在压缩衣服的物流费用，
我就会寻找一款真空压缩包。

写到这儿，我不禁又想起了当年的那个小哥。
希望他找到了一个心仪的岗位，做着喜欢的事情，
聊到自己的成功经历时，眼里依然透着光。

（完）

那个喊了十三声发物资的邻居

Mon, 11 Apr 2022 20:39:47 +0800

这次疫情我在上海这个风暴中心，
居家工作也使我对大大了解了小区情况。
居委书记住在我们楼，
隔壁住着一个三口之家，
楼下还存在一位以最大音量公放音乐的狂热刀郎粉丝。
但这一切都比不上那个喊了十三声发物资的邻居。

第一声呐喊是在早上开晨会的时候。
逐渐炙热的天气让我推开了窗，
温热的空气带着一句“发物资！”窜了进房间，
击中了不知所措的我，
一时间分不清是耳机里北京会议室的戏谑，
还是上海隔离中的压抑。

第二声呐喊紧随其后。
一声“我要物资！”以精准的主谓宾表达了诉求。
疫情褪下了马斯洛虚假的繁华，
让大家都在第一层级需求硬碰硬。
Mia 说最近的情景经常让她想到三体，
或许就是这种感觉吧。

第三声呐喊就没那么有力了。
“物资…”的尾音逐渐在风中散去，
四月带来了你的呼喊，
但曹刿不会骗人，三而竭。

第四声、第五声呐喊过了一会才传来。
“物资呢？发物资！”六个字混杂了不甘、不忿、不服，
两个符号也修辞了提问、反问、设问。
整个小区既处在白天的嘈杂里，
又处在呐喊衬托下的寂静中。
或许其它人也和我一样，
在微信里发“笑死，我们隔壁楼有人大喊发物资”，
同时扮演一个心情复杂的看客吧。

第七声、第八声呐喊来的十分意外。
笑也笑过了，我本来以为可以回归正常的线上工作。
但没想到邻居好像掏出了一个铁盆，
边敲边喊：“发物资！咚咚咚！发物资！咚咚咚！”
仿佛洗菜的铁盆临时被委以重任，
它便抖擞精神不负众望地发出了振聋发聩之声。

第九声呐喊稍微柔和了些。
可能是敲盆的声音也吵到了自己的耳朵，
邻居停下了手，但没有闭上嘴。
“物资！”这两个字的呐喊穿透我的耳膜直达我的心灵，
我不禁也想，还好我们抢菜有收获，公司有帮助，
才不至于在2022年体验儿时父母口中的艰辛。

第十声呐喊后来一直没出现。
我们小区一共是五六栋高层塔楼，
每栋楼住了一两千人，
疫情期间大家也难得在家集中做饭。
要是实在没菜了，
可以用邻居家的炒胡萝卜香味下饭，
我这么跟 Mia 开玩笑道。
可能是中午的油烟声盖住了这声呐喊，
这句“发物资”被大家有意识地错过了。

第十一声、第十二声呐喊带着一丝阴阳怪气。
“有没有物资！发不发物资！”的两句感叹号问句发泄出了一个月来的情绪。
在窗前坐着的我也站了起来，
想用双耳效应找一下这位大哥究竟在哪。
但找一句曾经的话，就像收一盆泼出去的水，
有回忆、有现场，但没可能、也没办法，
就像许多人的爱情就是这么结束的一样，
喜剧的背后是悲剧，悲剧的背后也是喜剧，
生活就是莫比乌斯环，
总是有人听到一个词就在乱用……

纷乱的情绪中，我似乎听到了第十三声呐喊，
又是“我要物资！”这句简单直白，但又希望渺茫的需求。
但我似乎也没听见这声呐喊，
反思了一下，
隔离的一个月来除了发过一次物资，
其它时间我也只能靠自己的手来抢菜、抢肉、抢蛋、抢奶。

让这哥们去喊吧，
希望他有吃有喝。
这么想着，我站起来，关上了窗。

（完）

再惠教会我的五句话

Thu, 24 Feb 2022 18:00:00 +0800

前阵子我跟洋神感慨，
这段在再惠的经历是我非常宝贵的财富。
今天或许是个合适的日子，
就让我挑拣一二，
把其中最亮的几颗宝石分享给大家。

本文适合伴以 Daft Punk 的 Veridis Quo 作为背景音乐，
这样你就可以获取与我写作时相类似的心境。

边工作，边生活

毕业后接触到工作生活两点一线的我，
心中一直萦绕着一个问题：
“虽然大家都说要 Work Life Balance，
但我究竟喜欢怎样的 Work Life Balance 呢？”

后来我发现，我所喜欢的状态，就是边工作，边生活。

入职再惠以后，某天回家我很兴奋地跟 Mia 感慨：
“再惠的队友们跟我是同类人！
他们追番打机，周末也会写代码！”

住在塘桥的我，很快交到了朋友，
与津铭、仲印、旭凤组成了4号线4雄。
不论是上班下班，
我们一边嘲讽 Python/Javascript 哪个更烂，
也一边吹捧说对方学到了廖雪峰/尤雨溪的三成功力，
有时还会聊聊多想买任天堂新出的 Switch 游戏机。

项目忙的时候我们也会在周六加会班，
有的队友期待加班时的加餐，
也有队友期待事情做完以后，
赌上奶茶的德扑大战。

在这样的环境下，工作与生活并没有写死的隔阂。
大家既是工作上的同事，
也是生活里的朋友，
我们也彼此互称为伙伴。
有些伙伴间化学反应过了头，也会发展成情侣，
光是我身边就产生了10对以上的情侣（总感觉哪里不对）。

大家并不把公司看作是“老板的公司”，
而是看作是“我们的公司”。
怀揣着同样愿景的人，
做事的时候也不会瞻前顾后。
去酒吧团建时，
一个伙伴还很兴奋地给老板娘推荐了我们合作的点菜机，
当然他义正言辞地否定了我们对他动机的怀疑。

对我而言，
工作本身就是生活，
跟喜欢的人做热爱的事，
这就是最好的 Work Life Balance。

谋其政，在其位

子曰：不在其位，不谋其政。
但我从一线开发到 Leader 的升级之路上，
体会最深的却是这句话的“逆反定理”：
谋其政，在其位。

有些职场伙伴会存在预期差的抉择：
“是先给我加薪，我再做更多事情呢？
还是先奉献更多，然后再谋求加薪？”
这个困境非常常见，
我总会选先承担更多责任。

往小了说，升职加薪需要理由或借口。
往大了说，创业的路径就是先在不确定性中寻找路径，
然后产生创造性的价值。

做点菜机业务还没招到Windows开发的伙伴时，
我握着刚学的C#开始上手。
做社群业务从零到一需要用户积累时，
我拉着地推就去扫码加人。
团队分工项目缺少责任人时，
第一时间举手自荐的也总有我。

权利与义务总是共生的，
不必过于在意他们的顺序。

或许这跟不同的公司有关，
再惠不吝于奖赏付出努力做出成绩的伙伴。
或许这也跟不同人的气质有关。
Mia 以后会变成“自由而无用的灵魂”，
但我的印记大概永远都是“选择了交大，就选择了责任”…

身段软，站得稳

工作前听“拥抱变化”四个字，
是没什么切身体会的。
直到工作了以后，才明白这四个字的重量。

在再惠我换过好几个组，
亲口通知了最好的朋友他被炒的消息，
经历过整个事业部的撤裁，
也看过水土不服的高管空降后火速撤退。

每次我都会想到台风过境后不受影响的小草，
身段软，站得稳。

身段软，意味着不骄傲、不自满。
CTO华哥从百度被挖来再惠以后，
并没有握锤找钉、把所有的流程百度化。
最终他以再惠的方式，
产销结合，
推进了最适合业务的产品技术。

身段软，也意味着不屈不挠不放弃。
在推行更高的代码标准、更严格的编码规则时，
一开始大家都无从下手，
屎山陋习过重无法推进，
但后来团队每个人都认可并做到了高标准。

不论是走出舒适区迎接变化，
还是尝试引入鲇鱼创造变化，
拥抱变化的最好方式就是微笑着面对他。

耐得烦，霸得蛮

做好事情要耐得烦，霸得蛮，
就像发条技师经常跟我们讲的一样：
“长跑比赛乌龟胜利了。”

再惠所处的本地生活行业，
非常注重对客户的服务质量。
给客户提供的优质服务，
就来源于每次服务的持续优质。

这也偶尔会给我带来精力磨损导致的疲惫，
但更多时候想想像二狗这样的伙伴也会在周六录一天主动营销，
我便很快会被彼此的斗志所感染。~~（总不能比二狗差吧）~~

即使是技术领域的工程化，
也需要持续地添砖加瓦。
我们最早的手动拉代码发布，
发展到到今天的调试发版报警全自动化流程，
所有的想法都是六年间的一个个 commit 铸成的。

人会对一蹴而就的抽卡感到兴奋，
但日月兼程的养成才是我的乐趣。

路何方？在脚下

我跟 Mia 戏称自己是 “米Boy”：
喜欢的是米娅，玩的是米哈游，用的是小米系产品。
我对小米一半的了解起源于雷军，
而我对雷总一半的了解起源于《R U OK》…

当我们能主导事业的方向时，
一定会问自己的问题是：“路何方”？
此时的回答就是“在脚下”：
不论别人说的怎么样，就是放手去做就好。

就像主站上灰度发布之前，
内部研讨总有觉得现在流量不算大，
流量路径尚未治理的各种担忧。
但只要真正去做了，
就会实际地发现灰度能有效地控制问题影响范围，
但也对代码兼容性提出了新的要求。

职场中也一样，
对工作、职位的判断也跟小马过河一个道理：
驼的是盐还是海绵只有自己知道，
水有多深只有走过去才知道，
真正的道路是自己双脚走出来的。

更多的选择往往不是幸福，
它带来的可能是更多的烦恼。
就如同苇名一心教导的那样：

“犹豫就会败北。”

—— 苇名一心

（完）

2021, 我微博没了

Sun, 16 Jan 2022 19:52:27 +0800

年底的某一天，
我日常地登上了微博，
收到了惩戒的一条消息：
@浮云微博没了？

被夹了

对我而言，
一方面这是意料之中的事情。
互联网服务之靠谱，
就像百度空间给我的体验。
另一方面这也是让人伤心的事情，
毕竟十年来我不在朋友圈感慨的肺腑之言，
都留在了微博里，
它也拥有着我素未谋面过的网友关系链们。

我尝试着去申诉，微博给我回了个邮件，大意是：
“经我们审核，你微博太黄了，所以被封。（注：永远无法解封）”

这让我很头大。
我既想要回我的账号，
又不想被迫承认我不涩。

朋友们知道我申诉无用以后，
纷纷为我鸣不平，
并让我展示下究竟我发啥了。

我很无奈，只是让他们关注了禾野。
只不过我的防爆红宣言或许得重新声明一次了：

写到这里，
我决定给微博举办一场小型的葬礼，
葬礼的内容就是我2021年的随想。

考完了

父辈们有着比我辈们多的兄弟姐妹，
可能这也是他们比我更能享受家庭温情的原因。

年初被小姨夫（我称呼为叔叔）的朋友启发了可以去“买个文凭”，
于是年末我跟 Mia 就一起去参加了全国统考。

面试还算顺利，笔试还算麻木。

因为很久没正经当过面试者了，
去母校面试的感觉尤其错乱。
这里多了一颗树，那里多了一个工地充斥在我考前的大脑里。

就像一个矛盾的闻一多，
我有时说了不做，做了不说，
但更多时候是先说再做，边做边说。

对我而言，想创业就像是要过河，
我知道最终我会在对岸，
也明白有许多种过河的法子。
但也觉得旅途还长，
总能再等等，
“优势在我”。

干活了

即使身处软件行业，
近两年我也能感受到从“反内卷”到“反卷”的思潮涌动。
有时我感觉这思潮像一桌人一起吃饭，
养尊处优的人劝面黄肌瘦的人“少吃点不健康的肉，多吃点健康的青菜”。

就像是被云朵裹挟一样，跟着走只因为飘了。

我时常感觉世界很多道理都是很浅显的，
就像是我小时候常听的那句“劳动最光荣”，
又或者是外公会念叨的“干活，然后吃五碗饭”。

天才的瞬间在日复一日的坚持下会变为天才的永恒。

啊，永恒。
对了，21年我最喜欢的角色是雷电将军。

变强了

年末的时候，我跟 Mia 感慨说三个目标都没达到。
体重来到了 145, 书只看了 10 本，投资收益在 -8%（然后元旦后来到了 -20%…）
不过我也安慰自己：“我比你弱没什么丢人的。”

我们互称对方公司为“学校”

有时我们也会讨论其他情侣的相处方式，
对比下来我们戏称自己为“互相竞争”。
毕竟考研前我半夜偷偷做数学题的行为，让 Mia 非常不屑。

翻看着 21年的自我，
相对论再一次地应验了：
过去的时间总是如梭的，
未来的时间总是煎熬的。

人在世界上无法独一无二地存活，
或许一千个人眼中只有一个哈姆雷特，
或许数学期望是五百多个，
或者也是一千个。
不过总的来说，哈姆雷特好像也跟我差不多，
一样地不孤独。

Python 这几年都更新了啥

Thu, 21 Oct 2021 20:26:58 +0800

最近我们终于全线升到了 py39/go117,
在大家对 go 新特性兴奋之余，
@ackerr 提了一个很犀利的问题：
“Python 新版本都更新了啥？”

确实，
除了 f-strings/dataclasses 这种大家可能熟知的功能，
新的版本究竟更新了什么呢？

以前 dota 一个小版本的 changelog 都能读的津津有味的我，
今天决定咀嚼一遍从 py36 至 py310 的更新日志 ~~（HOHO~~

以下代码片段都可以在最新的 Python 3.10.0 Repl 中执行。

What’s new in Python 3.6

Python 3.6 是在 2016-12-23 发布的，官方维护至 2021-12-23。
感知比较大的几个改动包括：

# 字符串拼接中，支持使用 f-strings 的 inline 拼接方法
# 终于能像 JS 那样方便地进行字符串拼接了
name = "ackerr"
precision = 2
height = 183.2
assert f"{name} is {height:0.{precision}f}cm tall." == "ackerr is 183.20cm tall."

# 常数定义中，可以使用下划线增加可阅读性
number = 3_735_928_559
magic = 0xDEAD_BEEF
assert number == magic

# 变量定义中，支持类型声明了
# 值得注意的是 Python 依旧不是强类型，只是写在了 __annotations__ 这个变量里
import typing
numbers: typing.List[int] = [1,1,4,5,1,4]
complex_data: typing.Dict[int, typing.Set[int]] = {}
assert "complex_data" in __annotations__

# 加了一个 enum.auto 的函数，开发者不用费心去自增了
import enum
class Colors(enum.Enum):
 R = enum.auto()
 G = enum.auto()
 B = enum.auto()

assert Colors.B.value == 3

其它的一句话更新包括：

Windows 上默认编码都设定为 utf-8.
修改了 dict 的实现，使其内存占用量比 py35 下降了 25%.
标准包 asyncio 更新了一大串功能，使其变得能用了.

What’s new in Python 3.7

Python 3.7 是在 2018-06-27 发布的，官方维护至 2023-06-27。
感知比较大的几个改动包括：

# 类型系统支持惰性求值了，可以不需要用字符串来指代自己了
from __future__ import annotations
class QuerySet:
 def filter(self, **params) -> QuerySet:
 """some database filter"""


# 新增了 dataclass 标准包
# 相比于 dict 传参大大优化了可读性
import dataclasses as dc
@dc.dataclass
class Person:
 name: str
 age: int
 gender: str = 'Unknown'

assert Person('me', '24').gender == 'Unknown'

其它的一句话更新包括：

async/await 现在是保留关键字了.
新增了 breakpoint() 系统函数用于调试.
可以通过定义包的 __getattr__() 来控制包变量的访问行为.
标准包 time 支持了纳秒级的精度.
标准包 asyncio 更新了一大串功能，使其变得好用了.

What’s new in Python 3.8

Python 3.8 是在 2019-10-14 发布的，官方维护至 2024-10-14。
感知比较大的几个改动包括：

# 新增了赋值判断的语法（也被形象地叫做海象操作符）
import re
if match := re.search(r"(\d+)%", "Total coverage: 80%"):
 print("Coverage is {match.group(1)}")

# 函数支持用 `/` 限制非命名参数
def calculate_data_length(data, /):
 pass

# 官方指出，这种情况 `calculate_data_length(data=data)` 的可读性显然更低，其实可以在定义函数时禁掉
# 而且该语法可以避免 `**kwargs` 传参冲突的情况
def get_values(data, /, **kwargs):
 print(data, kwargs)

get_values({}, data='some_data')

# f-strings 支持了自解释的语法
name = "ackerr"
assert f"Debug: {name=}" == "Debug: name='ackerr'"

# 新增了 `functools.cached_property` 方法，支持属性的缓存
import functools
class DB:
 @functools.cached_property
 def connection(self):
 print(1)

db = DB()
assert db.connection == None
assert db.connection == None

其它的一句话更新包括：

finally 语句中不允许使用 continue 了.
新增了计算欧几里得距离的方法 math.dist().
新增了支持混合l类型的 typing.TypedDict.
标准包 asyncio 更新了一大串功能，使其变得稳定了.
官方给出的 benchmark 中，相比于 py37 总体性能提升了 5%~20%.

What’s new in Python 3.9

Python 3.9 是在 2020-10-05 发布的，官方维护至 2025-10-05。
感知比较大的几个改动包括：

# dict 支持并集操作符 `|` 了
x = {"a": 1, "b": 2}
y = {"b": 3, "c": 4}
assert x | y == {"a": 1, "b": 3, "c": 4}
assert y | x == {"a": 1, "b": 2, "c": 4}

# 支持 `list`/`dict`/`set` 这样的原生类型作为类型标注
def occurance(names: list[str]) -> dict[str, int]:
 return {name: names.count(name) for name in names}

其它的一句话更新包括：

编译器由基于LL, 改为了基于PEG, 以便日后提供更强大的语言特性.
新增了 str.removeprefix()/str.removesuffix() 方法.
hashlib 支持了 SHA3/SHAKE 的计算.
非 Windows 平台不支持构建 bdist_wininst 了(所以很多第三方库没及时更新).
官方给出的 benchmark 中，相比于 py37 总体性能并无提升.

What’s new in Python 3.10

Python 3.10 是在 2021-10-04 发布的，官方维护至 2026-10-04。
感知比较大的几个改动包括：

# 新增了类似 switch+case 的 match+case 语法
def check(status_code: int, message: str):
 match status_code:
 case 200 if message:
 return message
 case 200:
 return "ok"
 case 400:
 return "bad request"
 case 500 | 502 | 503:
 return "something wrong"
 case _:
 return "not implemented"

# `typing.Union` 可以写成更优雅的 `|`
def add_all(*numbers: int | float) -> int | float:
 return sum(numbers)

assert isinstance(42, int | float)

# `dataclass` 支持 keyword-only 模式
import dataclasses as dc
@dc.dataclass(kw_only=True)
class Person:
 name: str
 age: int
 gender: str = 'Unknown'

其它的一句话更新包括：

优化了 Python 自带的各种报错信息.
增加了 zip(*args, strict=True) 强制校验等长的参数.
优化了 str()/bytes() 的性能，日常情况中快了 40%.

结语

可以看到 Python 作为一个“步入成年的”编程语言，
这几年并没有 Golang 的泛型、错误处理那样令人 excited 的更新。
但总体的语言迭代也是基于 Python Zen 的小步快跑。

对于开发者而言，只要第三方依赖允许，
保持最新的环境并不是一个很难的事情。

笔者关心的功能只是语言标准的一个子集，
读者们也可以在官网上找到更详细、更实在的 changelog。

下期（如果还有的话）可能会带来 go115-go117 的版本变更日志，
到时候再见 :)

（完）

HR与程序员的日常（三）：人才发展

Thu, 09 Sep 2021 22:00:38 +0800

“哎，刚跟同事沟通完为什么他晋升被拒。”
“哦？为什么呢？”
“因为他的位子没到那个位置。”

（一）

从 Mia 到卡夫亨氏已经有三年多时间了，
她基本上以内部管培生的路径做遍了各种工作。
最近一年 Mia 在做 CB (Compensation&Benefit)，
其中的职责之一便是审核员工的招聘加薪晋升事宜。

“你同事晋升被拒是怎么回事，展开讲讲？”
Lirian 十分好奇，开始捧哏。

“本质是他理解跟公司产生了偏差，
他以为自己努力工作一定就能晋升，
但其实他的岗位已经到头了。”

“噢噢噢，就是说这个岗位只要P6，
但就算他有P7的能力也用不着，
所以就不给晋升？”

“对，大概是这个意思。
不过P6/P7是阿里那一套说辞，
我们公司按B14/B13这么算的。”

确实，很多时候大家的理解都是“努力一定有收获”，
但放在工作里好像跟岗位很有关系。
Lirian 想了想，问：
“所以在工作中，不同的岗位确实有着不同的上限？”

（二）

“肯定的啊！”Mia接着说，
“虽然一家公司几千个人，
但就是有些岗位更能出彩，
上限更高。”

“确实的，公司岗位皆平等，但有些岗位更加平等。”

Mia 意犹未竟地接着感慨：
“排除专业技能来说，
一个岗位离业务越近、或者越不可替代，
这个岗位一般就很重要。
比如 HR 里面，CB 相比 SSC 肯定岗位更占优势一点。”

“就是这个道理！
怪不得好多人都觉得 HRBP 会比其他岗位更有职业发展空间。”

“就算是同样的职位，在不同公司的上限也不是一样的。”
说到这，Mia 做了个比喻：
“假如你们公司的招聘来说，
看拼多多给多少多少，
我们这个岗位也要给多少，
那你们 HR 估计要吐血了…
同样的职业，在不同公司也是不一样的。”

确实是清醒的认知，Lirian 点头。
“道理是这样没错的，但也有很多人不懂。”

突然 Mia 灵光一闪，问 Lirian：
“有些岗位虽然离业务近，但是可替代程度也高。
考考你，什么岗位符合这样的描述？”

（三）

“客服？专柜？”
略加思考后的 Lirian 脑子里首先蹦出了印度人呼叫中心的画面，
“他们离一线业务是近的，但岗位上限其实肉眼可见。”

“对，你说的没错。还有像一线的普通销售也是这样的。”

“咦，这怎么讲？”

“比如我们公司的销售是卖酱油的。
一线销售其实只是做执行，
把酱油上到某几个地点的某几个货架上就行了。”

“科学的，这样好像确实不需要很高深的水平。”
……
一阵沉默以后，Lirian 又好奇道：
“那为什么还有人愿意做这样的工作呢？”

“销售上限高啊！
况且只是一线销售容易被替换，
职位做上来了有这个能力了还是很稀缺的。”

“那客服呢？”

“呃…”Mia 迟疑了一下，
“哎呀，反正我不是他们，我也不知道他们想法是怎么样的。”

（四）

“所以其实公司里每个岗位都对应有评级的。
你这个同事就是以为自己能晋升，但被驳回了对吧。
这种道理也不难明白，他不懂就算了，他主管也不懂吗？”

“每个人的出发点是不一样的。
可能业务团队他们只会看到自己团队的情况，
但是像 HRBP 就能看到整条业务线的情况，
我们能看到全公司的情况，
甚至总部那边能看到各个国家的情况，
就更容易比较了。”

“嗯，维持一个相对的公平还是很重要的。
那听起来纵览全局的话，
全公司各个职位的评级、人才的诉求这种就顺水推舟地能做出来了？”

“对的，这个就是 OD 做的事情。”

又听到了一个没见过的词，Lirian 再次好奇了起来：
“OD? OD 是什么意思？On Demand?”

“OD 就是 Organization Development, 组织发展。”

“噢噢噢，战略级别的工作了属于是。
那你这个工作听起来很有前途啊，小伙子好好干！”
Lirian 拍着 Mia 的肩膀，替她给自己画了个美好的未来。

（五）

“不过很多大公司到后面，
老板都会请咨询公司的人来做这部分事情。
我们是做甲方的，这种时候还是乙方来比较合适。
所谓‘外来的和尚好念经’。”

“对的，我之前看 SAP 的业务分析也是这个道理。
像用友、金蝶他们带来的只是模块上的工作方式，
SAP 是直接搞定老板，
把老板想做很久的公司改革做了，
整套组织架构图给你扬了，
再顺便赚个软件费实施费。”

“只要能搞定老板，那不什么都好做。”

“也是…这么说来老板挺惨的，要一直被搞定。”

（六）

此时刚好散步到飞洲国际对面，
Lirian 与 Mia 准备右拐过马路，
话题也拐到了领导者的态度上。

“老板很多时候都不想当坏人，
此时就只能 HR 上了。”

“没办法，有限公司的职位分工就是如此。”

Mia 回忆了下公司业绩变动时的情况，接着说：
“就像之前业绩不太好的时候，公司首先就把外聘的岗位停了。
老板也不可能公开说公司没钱了，但财务跟人事还是一清二楚的。
财务就只管钱，别说有的没的，给我把钱给省下来。
但是人事这种时候就得当坏人了。
那阵子我们HR老大让所有招聘晋升加薪都得经过他，然后想尽办法拖延…”

我想象了下那个工作场景，叹了口气：
“可以想象很多人对他都会有怨言，
而且级别不一定还比他低，
估计老板也没少收到投诉。
这种时候 HR 还是得需要老板的鼎力支持啊。”

“那肯定啊，毕竟是背锅位。”

（七）

快到飞洲国际了，
傍晚散步消食之旅也接近尾声。

“我突然想到还有一个岗位：
离一线远，可替代程度高，但可能很重要。
你猜这个岗位是什么？是 EA。”

“EA 是什么东东？那个游戏厂商？”

“Executive Assistant. 执行助理。
做的差的就是端茶倒水打印文件，
做得好的就是真的部门二把手了。”

Lirian 马上叫道：
“哇！那我也想要一个 EA！
这样我就是一把手了！”

Mia：“想！得！美！”

（完）

Jeff Ehco Facts

Mon, 07 Jun 2021 22:07:09 +0800

最近认识了编程界的半壁江山 Jeff，
与本人确认过，
确实与传说一致，
特此记录。

Jeff 跟 Ehco 都是扇贝网的开发，但 Ehco 不一会儿就离职了，因为水镜先生说他们两个在一起太影响这个版本的平衡性了。
Jeff 是扇贝的核心开发，他一部分工作是给背单词的用户换单词卡。
扇贝不支持德语，是因为 Jeff 还没抽出时间学德语。
扇贝开放了编程课，因为 Jeff 发现他有余力教编程。
扇贝编程里，学生不懂问助教，助教不懂问扇贝工程师，工程师不懂问 CTO，CTO 不懂就会给 Jeff 提工单，Jeff 有空就会按优先级处理。
扇贝没有线上事故，因为 Jeff 都会提前写好复盘，然后提前修复掉。
扇贝几次宕机，都是因为 Jeff 在追综艺忘了处理前端请求。
Jeff 业余时间会看所有综艺。
《Rick and Morty》里看的电视综艺就是 Jeff 指导创作的。
金泰浩跟罗英石每次的争论，他们都会找 Jeff 做最终拍板裁判。
Jeff 偶尔会帮小米电视优化综艺页面。
AKB48/SNH48/NMB48 的 48 是 Jeff 的体重，代表了他在团里的分量。
Jeff 最近的愿望是等干反田爱瑠拍综艺，而 Ehco 在等龙女仆第二季。
Ehco 小时候叫 Echo，但他后来自己改了身份证上的名字。
扇贝的错题集由 Ehco 负责给返回值。
AbnerLee 与 Ehco 共事以后，才想好自己的软件叫 Typora。
Ehco 能用美式键盘写出 31 个字母。
Ehco 只要 1 小时就顶别人 8 小时，多出来的 7 小时在改单词拼写错误。~~是真的~~
Ehco 写前端喜欢从混淆后的开始写，因为这样变量名短不容易拼错词。
Ehco 的数据库技巧如此炉火纯青，以至于他一般只用 for 解决问题，而不是 MAX 或者 MIN 函数。
但 Ehco 与 Jeff 的联调也出现过问题，因为 Jeff 返回值给的太快，Ehco 错字还没来得及改完。
后来 Ehco 给 Jeff 加了一点安眠药，强制 sleep 解决了这个问题。
Ehco 在 PingCAP 的主要工作是给 TiDB 加钛。
TiDB 把引擎改为 Ehco 后，单机效率提升了 200%，但 Ehco 暂不支持高可用。
在 Ehco 的建议下，戴佳伟开始以“异灵术”的身份直播炉石传说。
Ehco 建议设计师把 Jeff 加入炉石传说，本地化翻译后为“杰弗里斯”。
当你向 Jeff 许愿时，他会尽量满足你的愿望，但注意他身边的 Ehco，小心别被篡改错别字成别的含义了。
毕竟 I want to be rich 跟 I want to be lich, 一字之差，失之千里。

（完）

我的奶奶

Mon, 31 May 2021 22:37:13 +0800

“工作累不累呀？”
“不累不累，我很喜欢工作的。”
“子岳要吃健康一点啊。”
“我知道的啦~”

不像袁隆平爷爷是一个很厉害的爷爷，
我的奶奶就是一个普通的奶奶。

粒米闯三关

小时候我爸妈常给我讲故事。
我妈会抱着我读《岳飞演义》，
我爸则会在睡前跟我讲各种他从小听到大的故事。

有一个叫“金鼓锣”的故事他来来回回地跟我、子南、恺恺都讲了许多遍，
乃至 Mia 跟我回家时也听了一遍这个故事。

小孩子对世界的好奇心是无穷的，
听完故事的我会缠着我爸讲更多故事。
但人有限的故事储备怎能满足无限的好奇心呢？
所以后来我爸也常给我讲他自己小时候的故事。

“你的妈妈是一个什么样的人呢？”
我问我爸，他想了想，说：
“你奶奶虽然没读过书，
但是她是有大智慧的。”

我对奶奶的认识，
便是在我爸这一言一语的描述中建立的。

后来小学时候，
奶奶来到广东陪着我们生活了几年，
我便也能亲耳听到奶奶跟我讲故事。

“粒米闯三关”是奶奶很喜欢讲的一个故事。
大意是苦命但善良的主角靠着一粒米闯过了三个考验，
好人有好报，教育我们要善良。

这个故事虽然没有反转、没有套路，
但它一直留在了我心里。

克勤克俭

奶奶在广东呆了几年以后，
最终还是要回到湖南老家去。
走的时候老人有点伤心，
可能是觉得以后再也难有机会来广东了，
便额外嘱咐了许多大道理与小琐事。

奶奶其实不是一个喜欢说教的人。
爷爷走得早，
奶奶一个人把抚养了好几个小孩拉扯大，
苦活也没少做。

她的子女们有了下一代，
下一代又有了下一代，
组成了庞大的“傅氏家族”。

几十年来，
她的生活用一句湖南俗语就是“克勤克俭”。

老去的她眼睛不好，
叔叔一直照顾着她，
奶奶也基本没有踏出过村里。

我寒假暑假去看她时，
她也就呆在屋里，
下午阳光好的时候搬把板凳，
坐在门口听着子孙们扯谈。
偶尔也会对轶事里懒惰的人发出评价：
“人还是要做事的，不做事不行”
然后转头劝她小儿子：“现在康康很好了，你可以少做点事了”

伸手不打笑脸人

奶奶在年前病情突然恶化，
年后便不在了。

当时 Mia 提醒我多注意我爸的心情，
因为岳父当时也是低落了一两年。

前阵子视频的时候，
我问我爸：“高考完你打算去干什么？”
他说：“唉，之前本来是打算陪完学生高考，就马上回湖南的…”
言语之间的失落难以掩盖。

我不禁想起了之前看《寻梦环游记》，
看到剧里面满脸皱纹的奶奶，
我也一下想起了我的奶奶。

coco 留下的是一首歌，
奶奶在我心里留下的是一句话：
“伸手不打笑脸人。”

上学时，我会笑着做题，
工作时，我会笑着写代码。
有时别人会觉得我很奇怪：
“人家上班你也上班，为什么你这么开心？”
我便会用 TVB 回答他：
“开心也是一天，不开心也是一天呀~”

人活于世上，
骨肉精血魂是他几十年所见所闻、所食所想汇聚而成的。
跟奶奶相处的点点滴滴虽然逐渐磨损，
但她讲的故事、坚持的为人处世、教我的道理却每每在晚上响起。

希望她像《狮子王》里说的那样，
成为了天空中繁星的一颗，
照耀着我们。

（完）

杂思丨近日状况

Wed, 28 Apr 2021 20:14:38 +0800

近两周在旅途上的时间不少，
看了两本书，
要写篇文章。
大概这就是“读在飞机，写在高铁”的都市虚假成年知识分子吧。

（一）

上周看完了一本《定投十年财务自由》，
除了学习到各种宽基指数，以及各种名词以外。

“十年”这样的字眼，
也像定期的心理按摩一样，
使我看得账上的 -15% 总收益慈眉善目起来。

就像巴菲特说过的那样：
“活着才有输出。”
不论你年收益率是 5% 还是 10%，
活得越久，总是收益率更高的那个。

当然了，虚空第一件装备就出龙心的时候，
“活着才有输出”这句话可不是有力的证词。

（二）

想到 dota，不禁感慨最近玩大型游戏的时间变少了。

以前总有人教育我：“游戏有什么好玩的，你长大了自然就不喜欢玩了。”
现在我才体会到，游戏是一种我挤时间也想玩的东西。

最近的时间也只够玩玩《明日方舟》这种上海本土游戏，
不过也是奇妙，我两年前访谈里一句“我喜欢玩明日方舟”，
居然认识了熊博士这个好友。

以至于我每个月给鹰角冲月卡，
都理直气壮地对熊博士说：
“给你男人发工资了，不用谢！”

（三）

“你工资里有我的一份。”
我也会对在莉莉丝干活的 hulucc 这么说，
不过这种歧义诱导生不了效，
他并不会给我返利。

只是以前 Mia 在看跳槽机会的时候，
会让我问 hulucc：
“你们这种二次元公司，HR 真的不需要强制 cosplay？”

我作为专业的传话中间人，
就像中学时候帮忙递纸条但一定会拆开看的同学一样：
冷静思考、放弃思考、大声赞扬、好！cosplay 好啊！

（四）

Mia 的跳槽之路比较漫长。

有个老美说过一句话：
随着逐年晋升，每个人都将被提拔到他无法胜任的位置上。

Mia 在现在的公司尽心尽力做了三年多，
一路高升，直系老板都换了四五个。
这导致工作 5 年的她，现在看的职位都要求 7 年甚至 10 年以上的工作经验。

“要不咱把加班时间算上，凑个十年？”
我在一旁出馊主意，Mia 不置可否。

不过被嫌弃年龄太小经验不足，
也确实是个幸福的烦恼。
不像写代码的，老是被嫌弃体力不如年轻人，
说的好像写代码就是青春饭似的！
这世上绝无这样的道理！
我祖上一直是程序员！
我至少能干到 36 岁！

Mia 赶忙安慰加速主义发作的我：
“没事没事以后我养你。”

（五）

可能是因为当成年人当太久了，
最近 Mia 与我都在讨论“如何健康工作五十年”这个话题。

在短暂的交流以后，
我们初步商定了以后我当 CEO，
她当 HRD 的分工。
鉴于“不与同公司 HR 发生恋爱关系”的职场原则，
我们也基本确定了不在同一家公司就职。

这个目标很明确，
就像高考只要 700 分就能上清华了。
冲啊！

不过俗话也说“多条退路多条路”，
我也安排了一下当不上 CEO 的退路：
可以去美团送外卖。
毕竟我现在了解单车的扫码与开锁、熟悉电梯按钮的点击与撤销、清楚“我能不能提前点个送达”的问询话术。

（六）

梦想归梦想，玩笑归玩笑。
认真考虑的话，未来的路还是要对自己负责。

以前跟 Mia 在交大散步的时候，
我们就会畅想以后会不会一人读书、一人养家。
最近发现时机合适，
我们也就生出了报考在职 MBA 的想法，
毕竟名人自传里，
好像都有一段一边工作一边读书的时光呢。

“那么问题来了，上海 MBA 读哪家？”
听到这个问题，我想也不想地回答：
“当然是交大啦！不然你还想当个自由而无用的灵魂吗？”

罪过。
向受影响的复旦灵魂们道个歉。

（七）

报考 MBA 首先要了解 MBA，
MBA 的全称是 Married But Available，
许多人通过读书找到了第一个或者第几个真爱。
但这个是考上了才要考虑的问题，不重要。

在面试的时候，
会有这么三个固定模式的问题出现：
“你为什么要报考 MBA？为什么选我们学校？你读完 MBA 的五年计划是怎么样的？”

这种问题一定要好好演练，
并且最好反复询问自己、重复回答。

于是我每天都在 Mia 耳旁念叨：
“闲着也是闲着，交大离家近，读完再说…”

好在 Mia 已经对爱搞事的我生出了免疫力了。

（八）

小学时候我喜欢看一个叫《信不信由你 Believe it or not》的节目，
里面会半真半假地讲述四个故事，
然后让嘉宾与电视观众们猜哪个是真的。

我也很喜欢跟朋友们讲述这类故事，
比如意大利面其实是一个宗教的神、
每个月的 14 号都是情人节、
12月12号晚上12点拨打12个0会听到“对不起你拨打的是空号”等等。

久而久之身边的同事朋友们也滋生出了免疫力。

希望以后通过我的努力，
所有中国人都能这么自信、自知、自强，
对谣言有抵抗力，
做到不信谣、不传谣。

（九）

京沪高铁此时已经驶过济南。
这次到北京与 ldsink/allen 短暂地聚了一次，
不知不觉他们创业也数载了，
都在感慨时间变化真快。

我上家公司有不少十年老员工，
但目前我司却一个十年老员工都没有，
真是气抖冷，吃人的互联网行业换血太快啦！

……

当然了，同样的道理也适用于 90 后程序员朋友们：
震惊！到现在为止，没一个90后程序员活过40岁！

（十）

年初的时候，
公司一个好友问我：
“你是如何在这家公司呆五年还不跑的？”

我论公司与个人的共同成长、论正确战略与慢就是快、论从零到一的异世界之旅讲了一通。
好友听的头昏脑胀，只得问了一句：
“所以其实你还是看好公司的？”

我仔细愣住，冷静无语，放弃推论，讲出大白话：
“当然啦！我要觉得我呆的地方不好，我早跑了！”

某种意义上，工作与谈恋爱也是一样的。
不管如何细数优缺点，
爱了就是爱了，
不爱了也就是不爱了。

（结）

除了投资类的书，
最近我还在看《西行漫记》（又名《红心照耀中国》）。

书中“一个党员的由来”一章，
看得我关联记忆不停。
一会儿是《金色的鱼钩》闯入脑海，
一会儿又是《小萝卜头》唤起回忆。

有许多事情，
当时看可能是平凡人做的平凡事，
后来回味起来却历久弥香，
浓缩成了一个个可以传下去的故事。

这或许就是时间的魅力吧。

（完）

我的金钱观

Thu, 18 Mar 2021 20:41:35 +0800

天生我材必有用，
千金散尽还复来。

前几天一次内部周常分享，
我讲了“事业计划”的话题。
果然，成年人们还是对“如何搞钱”这个话题最感兴趣，
在讲这一小节的时候，大家都放下了手机，热情地参与了讨论。

这几天我又细想了几回，
我对“如何搞钱”这个话题的理解，
其实就是“我的金钱观”了。
今晚可能是个合适的时间，
可以用个合适的姿势，
在博文里写下来。

财富在我理解中，
是由家族基业、劳动收入、投资理财、风险收益等多方面组成的。

家族基业

有的人用一生治愈童年，
有的人用童年治愈一生。

阶级论是最近甚嚣尘上的一种观点。
经过建国几十年的财富积累，
时运、机遇、奋斗导致了各个家庭财富积累的不一。
但撇去使矛盾激化的拱火观点，
“人生而平等，而有人更加平等”是一个确凿的事实。

在《全面战争·三国》游戏中有一个设定：
不同的势力基础家业是不一样的。
比如卖草席出身的刘备，虽是中山靖王之后，
但没有任何遗产，每回合只有0的家族基业收入。
河北袁绍，往上数四世三公，
不说继承的领土，每回合光家族基业收入就有4000之多。

人类也是如此。
不说“含着金钥匙出生”的王思聪、姚安娜、潘瑞，
即使是坐在同一个教室上着同一节课的学生们，
毕业以后也会发现，
家境的差别确实很难只用几十年的奋斗来追平。

当我们谈论个人的金钱时，
家族基业确实是一个需要直面的话题。

劳动收入

“听说搞IT的培训三个月就月入上万，是真的吗？”
“可以是真的。”
《链家小哥问我：听说搞IT的培训三个月就可以月入上万，是真的吗？》

劳动最光荣是中华民族的传统美德。
程序员朋友们的绝大部分收入都来自于劳动，
也就是码代码。
因为成年人最关心搞钱，
所以程序员聚集的地方大家都会讨论薪资、奖金、涨幅。

但除了算996时薪之外，
我很少看见有人会量化地去计算劳动的金钱转化率。
其实可以用积分的思想，
来估计一个当代程序员一辈子可以通过劳动赚取报酬的量级。

👆“写代码只是青春饭，生化环材越老越吃香”

我们以上图橙线（码农）的薪酬线，尝试做一个很粗糙的估计：

假设每级灰色横线代表 5W 的年薪差别
假设码农年薪最高点，38岁时年收入 48W
那么码农22岁起薪大概是 22W
健康工作五十年，70岁时年收入是 25W

在粗糙的估计之下，很容易得出一个结论：
程序员（码农）朋友们一辈子的劳动收入，量级是千万级。

大家可以尝试做一个量级的粗糙估计，
甚至可以加上“996拼搏三年”、“35岁收入断崖式下降”或者“40岁提前退休”之类的设定，
也可以得出类似的答案。

虽然一千万也是千万级，
八千万也是千万级，
但光量级上来说：
程序员健康工作一辈子，
劳动收入大概就是千万级。

所以许多程序员朋友对薪资不满意，
或许是他们处在更窘迫的青年时代，
又或许是他们的理想比千万这个量级要更广阔。

投资理财

👆“要做时间的朋友。”我这么安慰自己。

读完了《小狗钱钱》以后，
年初我就准备学习一个理财，
我便开始用工资买基金。
一月份买了 1W 元小赚 2% 以后，
我找 Mia 追加投资了 4W 元，
然后从山顶一直滑翔至今，
期间收获了无数的表情包、梗图以及段子笑话。

在《室友聊天》的年代，
我便抱着一种朴素的财富自由观：

假设工作 10 年攒够 100W，
只要我理财收益率能到 5%，
那我每年都会进账 5W，
省着点就完全够花啦！
就算考虑 CPI 什么的，
把本金、收益率想想办法搞一搞也没问题。

这种朴素的财富自由观，
一直伴随我到现今。
我也逐渐地往上打了更多的补丁：

一是，我大概也许确实会工作一辈子，
就算撇去自我价值的实现只谈钱，
10W 的年薪在 10% 的收益率下也相当于 100W 的稳定资产包。

二是，我对收益率确实不能太乐观，
5% 到 10% 我或许可以奢望下，
但 10% 到 15% 乃至 20% 是一个需要学习的系统工程，
毕竟巴菲特这么多年也才 20%+ 的年化收益率。

风险收益

你甘愿一直默默无闻，还是希望一鸣惊人？

—— 杰克 from 夜之城

财富某种意义上是很公平的。
有人可以一辈子只吃家族基业，
也有人的家族基业让他背上一辈子的负债。
有人杠杆短线成为股神一代传奇，
也有人一家五口接连在天台一跃而下。
所有的回报都伴随着风险，
每一条冒险路都有一个宝箱。

重疾险是一个确实值得购买的保险。
虽然许多企业已经把重疾险纳入了员工保障计划，
但个人而言是值得花时间去研究一下的。
有这么一个（危言耸听的）说法：
“一百万能治好很多病；
而一百万也治不好的，
可能五百万也治不好。”

重疾险是一款针对风险的兜底，
那期权、股票是一款针对收益的兜底。

zettaranc 在B站讲过他长期看好并持有李宁，
资产翻四倍的故事。
在我的观点里，
假如程序员希望获得比千万级更高的量级收益，
那么期权股票是必须要了解的。

不论是在市场上长期看好抄底持有，
还是以劳动附加价值的方式，
找一个小独角兽公司，
陪着它长大。

仓位管理

家族基业、劳动收入、投资理财、风险收益这四部分构成了一人一世的财富。
而其中不同的仓位占比，
甚至会影响到一个人的人生观、世界观、价值观。

比如“富二代”的财富构成中，
家族基业占比高达九成以上。
别说劳动收入了，
像投资理财等操作，
能有正向的收益就已经很不错了（参见 pandaTV）。

那对于家族基业占比九成以上的人类而言，
以财富的视角来看，拼命劳动完全没有收益。
这时候要么切换成“自我实现”的价值观视角，
要么切换成“我也不知道干嘛，但孝敬好父母就对了”的咸鱼心态。

那对于“奋斗逼”（中性），
为什么他要全身心投入工作呢？
因为也许他是一个财富积累主要靠工作薪资的人类，
劳动收入在财富中构成占比极大。
相比其它选择，
显然是加大自己对“劳动”的投入收益更高。

我的梦想是：
世界和平，
我爱的人跟爱我的人都能幸福，
我要成为温柔的强者。

而在我心中，
要实现我的梦想我需要远比千万级更高的财富量级。
以为人一世的时间维度去看，
家族基业、劳动收入或许只是我奋斗的一小步，
我真正要做的，
或许是把再惠做上市以后（x
某一天去创立一份未竟的事业，
有可能的话兼济天下，
大庇天下寒士俱欢颜吧。

杂记

我总跟 Mia 念叨：
“别看我们现在不富有,
but we will be rich.”

Mia 也总是安慰我：
“我没你那么志向远大，
我尽量在你 35 岁失业的时候能养的起你吧。”

（完）

我言、我知、我行

Mon, 15 Mar 2021 23:03:39 +0800

“人家是说了再做，我是做了再说。”
——闻一多

言易知难，知易行难

人活在世界上，诉说着、思考着、行动着。
标题的这句话，就是我对人类交互的一个思考。

言，说话，是人类最基础的一个交流功能。
人类是一个奇特的物种。
像《乡村教师》里感慨的那样，
明明信息交流只能靠喉咙震动通过声波传播，
但文化硬是传承发展了几千年。

知，思想，往往只能通过说话来表达。
在工作以后，
不少朋友会感慨很少有机会能跟他人深度交流了。
他们偶尔会怀念学校时候的夜聊，
虽然可能大部分时候讲的是学习、老师、校园的日常，
但也总有成年人独居生活时不会发生的人生、世界、价值的探讨。

行，行动，因为过于具象而经常被忽视。
而行动，却是这三者中最能表达立场的铁证。
不论是极端的“父亲的爱逼死孩子”中错位的表达与行动，
还是日常经常发生的“白天一起玩晚上偷偷学习”中流露的真实认知，
无一不说明着行动本身的价值。

所以说，言易知难，知易行难。

学习·教育改变命运

在我上学的年代，
考完试以后大家对完答案，
就会互相捧对方：
“哎呀我这次雪崩！”
“周神你肯定又第一啦！”
“学渣啦我也就三流成绩！”
结果成绩一出来，
排名竞争更加激烈。

学习、教育上，
说话只要重复一句“教育改变命运”或者“啊呀也太卷了”的抱怨就行了。

但“认为教育是能改变命运”的这种思想其实是更难得的（虽然中国很普遍）。
《贫穷的本质》中提到，
统计学上越富裕的人越舍得在教育上投资。
这也是一种思想的偏好。

行动本身就更难了。
现代学生除了懒惰还要抵御电子产品的诱惑，
成年人也如是，
许多人不仅放弃了读书的习惯，还放弃了探索未知的好奇心。

所以真的贯彻“教育改变命运”，
不能只靠口号，
也需要知行合一地持续付出。

事业·穷则独善其身，达则兼济天下

面试的时候除了专业问题，
我有两个喜欢问的个人问题。
一个是“给我讲讲你最喜欢的一次项目内容”，
另一个是“你以后想成为什么样的人”。
虽然可能会有离题的回答，
但我不止一次在一双眼睛中看到了燃烧起来热情的火光。

关于工作本身的社会舆论一直在变化，
从以前的“支持宣扬狼性文化”到现在的“警惕提防996资本吸血”也不过数年时间。
但随着舆论两边踏浪的大众，
会有多少人真正思考过自己的事业、阶段、坚持、独特、苦难与成就呢？
个中之人，能坚持自己独立思考并走一条不后悔的路也是少之又少。

之前与Mia聊天时，提到过一个好玩现象，我称之为“沉默的大多数”。
在我们观察中，群体对公司的看法往往是单元的，但个体的行动却是复杂的。
比如一个团队中，内部以公司不好的看法为主流，那认为公司还不错的员工也不会发声，以免被孤立。
但同样的团队，却也能表现出韧性，工作上的困难能客观分析并解决，并且离职率保持在可接受的范围内。

所以在攀登事业山峰的路上，
会有复杂的舆论干扰人的想法，
但最终最确定的，还是抛去杂念、端正认知以后一步一个脚印的行动。

爱情·这简单又强烈的感情支配了一生

与朋友们聊天时，经常戏谑一句话叫“男人的嘴骗人的鬼”。
去年流行的“小丑竟是我自己”的舔狗2.0这个梗，
本质上也是心口不一导致的戏剧化满载。

《新鸳鸯蝴蝶梦》里唱到：
是要问一个明白，
还是要装作糊涂？
知多知少难知足…

同一件事情，
叠加上言、知、行三者，
真值就有八种可能性。

所以为了避免误会、揣测、猜疑等古典狗血，
一条可行的路是三者合一：
我言、我知、我行。

但复读“不以结婚为目的的恋爱都是耍流氓”的人，
有多少人是真的这么想的呢？
又有多少人能真的这么做到呢？

生死·或重于泰山，或轻于鸿毛

就如同在《消逝的此刻》中感慨的一样，
我一直不太能接受“人固有一死”这个事实。

有这么一把达摩克利斯之剑悬在头上，
我便执行着战术上重视、战略上藐视的策略。

“死亡，不足为惧也。”
我说着这样的话。
同时每天躺在床上看着天花板，
我开始了三省吾身：
“明早吃啥？明中午吃啥？明晚上吃啥？”
噢不好意思，没吃饱，想岔了，我又开始了三省吾身：
“今天有什么话我能表达的更好？
我有什么想法是不该有的？
未来我要怎么改变自己的行动？”

今天的我比昨天的我更好了，值了。

知行合一，言行不一

真正去观察着生活，
就感知到“言易知难，知易行难”就像是宇宙的规约一样，
限制着人类的交互。

假如你是个知行合一的人，
那么恭喜你，
你现在的状态是我设想中的完美状态，
剩下的就只需要调整说的话，
表达自己就行了。

假如你意识到“知我”与“行我”是部分分裂的，
那也恭喜你，
你的意识更加强大了，能超脱地观察自己的言行了。

而倘若摄像机调转方位，
我们来观察芸芸众生，
就会发现大地上战栗的一个个个体。
他们的“言我”、“知我”与“行我”，
或隐藏、或纠结、或一统、或漠视。

这种时候，掏出绝世武功一看，
上面释义“让行动与认知统一、但不必说出来”的一句话赫然在目：

知行合一，
言行不一。

（完）

我的世界观

Wed, 20 Jan 2021 22:31:35 +0800

罗马军队大破希拉库扎国时，
一个带头挥着刀冲锋的士兵被一位蹲在地上的老人挡住了。
士兵吼着：“给我滚开你个老家伙！”
老人头都没抬地说：“不要弄坏我的圆！”
阿基米德，死于公元前 212 年。

（一）

最近跟 Mia 在路上玩猜人名游戏，
一方想人名另一方问，
问题只会得到“是”或“不是”的答案，
如此反复直到猜出来或者猜不下去。

当我猜出来 Mia 想的是阿基米德时，
我脑海中除了 Aha moment, F = P水gV排，
还浮现出了本文最开始的那个故事。

就像《百年孤独》的经典开头一样，
《进击的巨人》开头语也为粉丝们津津乐道：

那一天，
人类终于回想起来了，
曾经一度被它们支配的恐怖，
还有被困在牢笼的那份屈辱。

数学本身，也像这样的文字一样，
即使经历了数次危机，
也在费马、牛顿、高斯等伟人的掌舵下成为人类智慧的源泉。

（二）

即便是小学级别的数学，
也会让人有仰望天空的冲动。

最开始从整数、小数，
了解到了负数、分数，
再到无理数、复数的认知过程，
我就像一个第一次被放在星空下的孩子，
看着满天前辈留下的星星，
闪烁得一句话也说不出来。

那个时候坐我舅开的车，
他是当时我身边的最“理科”的人了，
我跟他讲述了我的新发现：
“Π是个无理数，意味着我们对Π的探索就是无穷尽的，也意味着Π里面可以含有全世界！”

后来细细想来，
Π一个数字包含的随机混沌，
就是我认识的世界的本质。

（三）

04年的时候看《儿童文学》，
里面连载了一篇李志伟写的中篇小说《圣域传说》，
情节跟后来的《异次元骇客》异常同步。
大致讲的就是主角创造了一个电脑世界，
但后来主角发现现实也不过是被创造的另一个虚拟世界。
这样的套娃故事简单来说，
可以通过“我思故我在”的思辨逃避过去，
但当时给我的冲击不亚于第一次看完《楚门的世界》的重生感。

从那时候开始，直到现在，
我一直在思考这个问题：
“我是谁？”

那时留校培训，我们几个好伙伴会挤在一间寝室睡觉。
晚上夜话时，我跟 FHN 聊到了世界观，
我说了“世界有可能是被创造出来的”后，
他拍床而起：“对！我也是这么觉得的！”
后来我们一电脑室的人都在《Ever17》中找到了观测者原理的绝妙故事。

中学时，我非常敬佩教我物理的万老师，
那时他是我认识的最“理科”的人。
在一天中午，跟他讨论完题目后论道中，
我顺着逻辑说出了一段日后反复咀嚼了十几年的话：

人生是没有实际意义的。

为什么呢？我们来尝试反证法。
首先假设人生有意义。

这个意义是寄托于心灵（意识）的吗？
不是，因为我只要否定心灵它就不存在了。

那这个意义是存在现实世界（物质）的吗？
不是，我相信科学，我不信来生。
宇宙会毁灭，一切物质都会消亡。

所以，论实际意义的话，
人生就是没有实际意义的。

在物理竞赛题目上能教导我的万老师，
对这番“中二”的言论也是无语，
挥了挥手让我自己去继续我个人的思考了。

（四）

所以我困惑就更大了。

人生没意义的话？为什么人还要活着呢？
但我迷恋于雨后路边浮上来的扭曲蚯蚓壮观场面，
揪心于恋爱时两颗心撞击的揪心情感，
沉浸于游戏版编码思维宫殿里的心流。
那世界肯定有一个理由，让我灿烂地活下去。

于是我寻找了许多的思想实验。

《毕业五年-回忆》里，提过一嘴“忒修斯之船”，
前文里提到的基本上类似于黑客帝国式的“缸中大脑”，
我心中还坚信的是一个《信条》式的宿命论。

有些人二十岁就死了，八十岁才埋。

这是一句《读者》里鸡汤故事的典藏句子，
但在我眼中却包含科学的“宿命”的含义：
只有在八十岁回首往事时，
才知道这个人二十岁就死了。

当你老了，回顾一生，就会发觉：

什么时候出国读书、
什么时候决定做第一份职业、
何时选定了对象而恋爱、
什么时候结婚，其实都是命运的巨变。

只是当时站在三岔路口，
眼见风云千樯，
你作出选择的那一日，在日记上，
相当沉闷和平凡，
当时还以为是生命中普通的一天

虽然古人云了又云：
“人定胜天”、“路在脚下”、“事在人为”
但是从未来的视角看来，
非洲的蝴蝶必然会振动翅膀，
章北海按钮必然会慢下几秒，
张华、李萍和我也必然有光明的前途。

（五）

三观中的世界观，
讲的就是我对世界的观感。

经济学里的这句话，
放在普世观点里也或许成立。

过去十年里，这是最坏的一年。
未来十年里，这是最好的一年。

“人生是没有实际意义的”这句论断，
在我的人生观里留下了深刻的影响。
但我的世界观里，
我给自己写下了这么一句话：

唯心地思考，唯物地活着。

这也是我博客站点名字“浮云计算”、以及我网名“浮云总是梦”的由来：
世上万物就像天上的浮云一样，
既具体、又空心，
既实用，凝集降雨泽润大地，
又虚无，让人欣赏变幻莫测。

或许智人的历史长河中，
就有这么一朵调皮云，
在一个晚上它飘在大地上，
挡住了一个仰望星空的智人的视线，
把这份仰望星空而对世界产生的好奇，
推迟了那么几百年。

（完）

为拼多多而死，不值得

Tue, 05 Jan 2021 20:21:20 +0800

润肺的离去，
是个悲剧，
也是一个警钟。

（一）

最近所有群都被拼多多员工（花名“润肺”）离世的消息刷屏了。

网上信息爆料说，润肺是一名98年的女生，在新疆的拼多多买菜工作。
2020年12月29日凌晨一点半，她在下班路上晕倒，抢救无效而离世。

此次事件还因为两点而被放得更大：

一是润肺同学并不是刻板印象中闷闷的程序员，
而是一个积极乐观、大学玩过乐队的运营妹子，
而且她的公司签名是“肺宝为多多守边疆”。
这让包括程序员之外的更多同学，也与润肺有了共情。

二是拼多多公关“辟谣式造谣”，
引发知乎官方下场对峙拼多多的低水平公关。

这种“黑历史打脸”式的操作引发了吃瓜群众的狂欢，
以沙雕行为迅速出圈，
在更大范围内施加影响的同时也引发了不小规模的刻奇行为。

整场时间在一周后并没有完全被遗忘，
反而引发了诸如“反资本家反996”
“在下班路上猝死，算工伤吗”等系列可能会影响更深远的讨论。

“这是一个影响深远的选项，请谨慎选择”

（二）

从社会的角度，这可能是历史河流中上的一只小蝴蝶。

随着网民年纪的变大，自媒体话语的放大，
这件事情与最近其它的几件事情一样，都引发了类似的讨论：
人为什么而活。

马云在三年前还是“马云爸爸”，但最近被叫的最多的还是“资本家马云”。
前几年还经常能见到华为狼性文化、阿里文化价值观的通稿，但最近这些文章的评论区只能控评。
更不用说去年刮起来的“内卷”“PUA”之风，也不知道它们能不能在汉语体系中留有一席之地，
还是与“屌丝”一样失去了最初精准的内涵。

大事件对长远的影响，我们可以看看历史。
与这次事故对应的，由近及远我想到三件事：
拼多多优惠券事件，导致了企业内部的整顿，似乎并没有影响到社会层面。
滴滴乐清女孩遇害案，督促了网约车安全体系的改革、监管体系的完善。
富士康连环跳楼惨剧，引发了全社会对于“血汗工厂”的讨论，把“员工也是人”的这种最基础的思想重新宣传了一遍。

这次的蝴蝶会产生什么样的效应呢？
我不确定。
但它一定会改变社会的一部分，
可能是我们一部分的共识，
又或者是一部分我们的生活方式。

（三）

从互联网从业者的角度，这又是一个鲜血淋漓的例子。

Mia 跟我讲过，她在的公司有个不成文的候选人模型，叫：
“Poor, smart, desire to be rich.”
（穷，聪明，渴望有钱）

互联网的工作模式也是类似的，
以“两个人拿三个人的工资干四个人的活”这样的方式，
吸引了一大批聪明人在这样的公司奋斗。
在上海，拼多多的薪资是独一档，
之前我们面试看中的好几个优秀候选人，
都以至少 50% 的薪资差价被拼多多吸走了。

不过讲到比惨，似乎总有更惨的，比如“生化环材”的同学就会说：
“我们也不比互联网轻松啊，互联网至少拿的多啊。”

确实。

况且这只是同时代的横向比较。
假如是跨时代地去比，
就更容易把话题引向了“宁为太平狗，莫作离乱人。”的感慨了。
所以说：

一个人的成功，
当然要靠个人奋斗，
但也要考虑到历史的进程。

（四）

从个人的角度，假如类似的事情发生在自己身上，
我会感到很不值得。

知乎宇宙里有很多脑洞题目，其中有一个叫
《假设有个游戏，你可以无偿获得五千元，但有百万分之一的几率会当场毙命。那么你会玩多少次游戏？》
理性人们给出的回答是：“这个概率？我能玩到你破产！”

炉石传说这款游戏因为随机性很大，
里面也经常有各种各样的概率性斩杀问题。
疯狂的玩家们给出的回答是：“斩杀概率肯定是 50%，因为要么死了，要么没死。”

这当然是风马牛不相及的两件事。
但在我眼中，生命的道理也与之一样：
“人固有一死，或重于泰山，或轻于鸿毛。”

我并不欣赏“计算 996 模式工作十年后全身而退的收益比”这样的行为，
但我非常敬佩那些“明知不可为而为之”的“最美逆行者”们。
假如公司是你事业的一部分，那么为之奋斗吧，
否则请一定要爱护好自己的身体，以投身于更大的革命事业中。

最后，引用保尔柯察金这段话，作为给大家美好的祝愿：

人生最宝贵的是生命，生命对于我们只有一次。
一个人的生命应当这样度过：
当他回忆往事的时候，
他不因虚度年华而悔恨，
也不因碌碌无为而羞愧。
在临死的时候，他能够说：
“我的整个生命和全部精力，
都已献给世界上最壮丽的事业
——为人类的解放而斗争。”

（完）

软件工程实践之网段管理

Sun, 13 Dec 2020 21:48:22 +0800

软件工程实践系列文章，
会着重讲述实际的工程项目中是如何协作开发软件的。
本文主要介绍了如何规划、搭建、管理网段。

outline

本文包括以下内容：

concepts: 网段中的概念都很基础
- ip/cidr: IP 是服务的点，而 CIDR 就是描述它的面
- vpc/subnet: VPC 就是云服务提供划分网段的工具
boundary: 网段的设计核心是边界划分
- scene: 利用场景维度来划分，以区别开发、测试、生产环境
- network: 利用网络维度来划分，以区分外网、内网
example: 实际开发中的例子
- ipsec: 用作 VPC 打通的常用工具
- openvpn: 用作连接内网的常用工具
conclusion

Concepts

在我们日常开发中，
只要用到网络就一定会跟各类网段打交道。
很多时候网段作为一种稳定的基础设施，
我们并不会注意到它。
但是关于网段、网络的一些知识，
是确实在软件工程过程中需要考虑的。

IP and CIDR

现代网络中，
IP 是服务的点，而 CIDR 就是描述它的面。

IPv4 的类别分类

列举一些能想到的 IP，会包括：
127.0.0.1 这个约定的本地地址；
8.8.8.8/8.8.4.4 这个谷歌提供的 DNS 地址；
59.78.3.25 这个上海交大东三楼的 IP 地址…

而 CIDR 则是描述一系列 IP 地址的修饰符。

比如 59.78.3.25/32 代表二进制前 32 位都严格与 59.78.3.25 相等的 IP 地址段（也就是特指这个地址）。
类似地，10.0.0.0/16 就是以 10.0. 开头的 IP 地址段。

VPC and subnet

AWS 作为云服务的始祖，
它开创了 VPC 服务让用户配置自己的网段，
后来 VPC 也逐渐成为了云服务的标配。

VPC 之间可以相互隔离，也可以打通。
（这里的隔离与打通，指的都是软件上的）
一般 VPC 会用作区分生产、开发环境。

比如我们可以在云服务上开两个 VPC，
生产环境的 CIDR 是 10.0.0.0/16，
开发环境的 CIDR 是 10.1.0.0/16。

而 VPC 下面可以拆分 subnet (子网)，
subnet 需要有更加具体的 CIDR，
比如生产环境的子网可能会是 10.0.0.0/24,10.0.10.0/24 这样的。

Boundary

网段的核心是边界的划分。
而划分好网段的目的，
既有安全性的考量，
也会利用异地达到高可用容灾的目的。

Scene

云服务一般在全球各大城市会设立数据中心，
每个数据中心会有多个机房，
我们网段的边界至少得以这个为界。

比如线上服务会跨机房部署，
分布在多个 subnet 中，
当某个机房发生清洁工拔电插吸尘器之类的事故时（一般不会发生）
服务能做到高可用。

subnet 级别还能配置网络流量的进出权限，
这点特性可以用来规划内部网络权限。

比如我们可以划分“外网可进可出”、“外网只出不能进”、“外网不可访问（仅可内网访问）”三类 subnet，
以部署不同特性的服务（负载均衡、普通业务、数据库）。

Network

网络流量走的是内网还是外网也是值得考量的因素。

除了安全性因素以外，
一般的云服务商给外网流量定价 1元/GB，
价格因素也是一个需要考虑的点。

大部分时候，开发可以严格遵循分层的原则，
所有前端走的肯定是外网 API，
所有后端走的肯定是内网 API，
只有负载均衡、网关层考虑内外网转换的问题。

还有一些时候，可以通过 DNS 自动配置流量网络。
比如默认 api.liriansu.com 指向负载均衡的外网地址，
但是修改内网的 DNS 使其指向负载均衡的内网地址。

Example

最后再附加一些实际开发中的例子。

IPsec

在业务庞杂了以后，
就会遇到跨云服务商的开发场景。
跨云服务商的内网打通，
一般会用 IPsec 这个工具，
云服务自己提供的 VPN 服务也是基于此的。
IPsec 的本质是起两台能外网互通的服务器，
互相转发流量。

比如要配置阿里云与亚马逊云互通的步骤大概会包括：

两边搭建 VPC/subnet (CIDR 不重复)
两边各起一台有公网访问地址的机器，装好 ipsec
- 配置 ipsec 证书、密钥等
- 打开 ip forwarding, 配置好 iptables 防火墙规则
- AWS 注意关掉机器的 source/dest check
subnet 路由表配置跳转至 ipsec 机器
打开两边的安全组，即可互通访问
- traceroute 命令可用于检测跳转

OpenVPN

我们还会遇到的一种场景，
是开发环境接入内网开发。

这个一般可以用 OpenVPN 之类的工具打通，
但鉴于目前我们还是用的手动流量转发的路子去搞的，
等涉及这部分了再在之后的文章里分享吧 :)

Conclusion

网段管理是跟开发息息相关的基建，最好能尽早规划好
网段规划的核心是边界划分，主要考虑安全性与高可用
云服务的基础概念是类似的，需要考虑好跨云服务、开发测试生产等多维度网段
内外网流量的复杂因素，可以通过分层或者 DNS 的方式屏蔽掉

（完）

毕业五年的报告之未来

Sun, 15 Nov 2020 21:00:54 +0800

每一年的生命都很重要，
每一年我也总想获得些不同的经验。
现在的我，
相比于毕业三年时的我，
更加接受了一个事实：
“狭义上，我也是个成年人了。”

广义上的成年人，
可能是年满十八岁。
狭义上的成年人，
是像成年人一样思考、
像成年人一样生活、
并且自认为自己是成年人。

当然，这话很有那种
“有些人20岁已经死了，但60岁才埋”的中二感觉。
所以请让我仰望星空，
讲一些脚踏实地的，
对未来的思考。

生活

大学时期对未来的畅想比较随意，
觉得以后可能会在上海开分基地，
也有可能肉身翻墙，
或者是回广东进入“父母在，不远游，游必有方”的状态。

但随着成年人生活年岁的增加，
肉身翻墙的吸引力逐渐下降了。
一方面是觉得自己的祖国挺温暖的，
另一方面是习惯了以后，
也没觉得网络环境多么不便了。

回广东的话，我确实可以“父母在，不远游”，
但 Mia 就会“父母在，远，回家得游”…
以前我总觉得相亲条件里“本地人优先”这一点并不科学，
但现在，我也算理解了这个想法的出发点了。

按目前的想法，
我应该会活在上海这个很舒适的城市里。
气候、交通、机会这些因素我并不看重，
我喜欢的是大城市的~~人口福利~~科技辐射跟君子慎独的城市文化。
科技辐射是指所有民用科技会首先从大城市开始普及；
而君子慎独是指上海这地方很讲规则，
并不是人情优先的。

不过按照我突发奇想、喜欢折腾的性格，
以后去成都跟大熊猫一起生活、
去泰国新加坡印度尼西亚、
去德国科隆住下也确实是未可知的事情呢。

职业

虽说在哪生活是未可知的，
但是做什么工作我其实很清楚：
做能让技术发挥影响力的事情。

排去可能性比较低的当业务出身的 HRBP=>HRD 这条职业路线，
能让技术发挥影响力的职业选择，大体上就是：

专家路线：利用某个领域的深入造诣创造价值，代表职位比如资深工程师、架构师
经理路线：以软件工程方法管理项目，代表职位如项目经理、技术主管
资本路线：以技术贡献入股，并参与公司级别的经营管理，代表职位如技术VP、CTO

专家路线下限高、上限不低、机会也多。
有朋友跟我讲过他的跳槽策略：
挑着C轮/D轮的独角兽公司去，
一两年公司上市，四五年期权变现，
如此反复，在大公司锻炼的同时，也能获得非常可观的报酬。
大体量的公司往往能锻炼并使用到屠龙技，
随着技术力的上升，
未来像 Linus/Donald-Knuth 一样的专家/科学家也定会人才辈出。

经理路线更偏工程向，跟公司绑定更深入，同级别影响力也更大。
某种意义上，
软件行业像是画家与工厂的结合体。
既讲究灵感设计与积极性，
又讲究管理科学与计划性。
好的经理能在管理、成本、协作的基础上，
保证最终产品的惊艳质量，
像张小龙、雷军这样最终会被冠以“产品经理”的桂冠。

资本路线则机会更少、风险更大，
但人最宝贵的就是梦想。
走这条路线的，
既有做到了拼多多CEO的陈磊，
也有从饿了么早期做起，但最后却黯然离职的叶峰。
更多的是名字被世界吞没的人，
他们也只能在下一份工作面试时，
在简历里写上“上一份工作：创业（失败）”。

按照我现在的年龄与技能点，
这三个方向完全都是可以去尝试的。
专家（纯技术）路线能快乐地写代码，
经理（偏管理）路线可以完成更完美的产品，
而资本路线，可以把技术的美妙带给更多的人类。

行业

这五年多在技术行业里工作，
除了一大堆的普世溢美之词，
我对这个行业的两个特质感受非常深：
终身学习、极致分工。

终身学习从正面来说，
就是认真对待每一个知识，
永远像十五岁的学生一样去认真学习。
从反面来说，
就是做技术的人只要懈怠了，
就会被刚毕业的同学们超越。

软件技术就像在站在巨人的肩膀上的巨人的肩膀上的巨人的肩膀上去眺望一样，生生不息。
现世代所流行的应用层技术，
一部分会沉淀成后世代的底层技术，
而另一部分则会消失在世代更迭里。

所以刚毕业的优秀同学们，
因为年轻，有许多时间学习当下的技术。
不论是薪资还是实力，
很容易就把懈怠的技术人超了过去。

那些期待着靠工作年限、工作经验来积累职业资本的人，
往往是很难在技术行业生存下去的。

极致分工的意思，
其实就是“软件工程师就是信息时代的工人”。
（附带说一句，这也是最近阶级论在软件行业思潮里很受欢迎的原因）

这个比喻本意是无奈的技术行业从业者自嘲，
但是它可以引申出来一点：
技术行业（特指程序员）缺少传统意义上的社会价值。

在生活里，
医生朋友能给你健康意见；
律师朋友能给你法律建议；
销售朋友给你介绍了工作里认识的朋友，有医生也有律师；
但是程序员的工作只有月薪。

于是看到了这一点的程序员们，
会积极地与人交互，
保持稳定积极的社会关系。
但也有很多程序员，
在朋友问到“能不能帮我写个小程序”的时候，
只能回答：“我是后端，不会写前端。”

而终身学习、极致分工这两个技术行业特质，
是在考虑“健康工作五十年，幸福生活一辈子”时无法回避的两点。
有朋友在打算 35 岁攒足够的钱提前退休，
也有朋友考虑好了年纪大了就换行，
去参与本地生活服务业的建设了（此处指送外卖）。

价值

因为思考未来，
所以人会思考自己的价值，
生活的价值、工作的价值、存在的价值。

再惠（我在的公司）的愿景是“让美食生意更轻松”，
关于我工作我之前也写过一些文章。
从价值角度来讲，美中不足的主要有两点：

其一是餐饮这个成熟的服务行业里，
技术能发挥的作用已经被探索了许多了，
相比于再多一个小的功能，
客服一次及时的响应更能让商家、消费者安心。

其二是餐饮行业虽然高频、市场大、机会多，
但并不能经常“改变人的命运”。
“改变命运”的行业，
人们称之为“新三座大山”：
住房、医疗、教育。
正是因为这几个行业的基础性以及重要性，
国家政府制定了非常多的调控政策。

倘若未来某一天，
我准备出门去创业搞搞事情，
那我或许会先考虑好，
如何在这三座大山里找到我的价值。

不过在那之前，
我还是先徜徉在代码的海洋里吧 :)

梦想

人考虑现实问题时，容易忘记梦想；
但仰望梦想时，现实问题仿佛都不重要了。

在我的自述里，我以前这么写道：

我的梦想是世界和平，好人都能幸福，
以及要成为一个很厉害的人。

现在我有了更具象的描述，叫：

我的梦想是：
世界和平，
我爱的人跟爱我的人都能幸福，
我要成为温柔的强者。

有的时候觉得语文真的挺神奇的。
梦很容易，想也很容易，
但梦想感觉却没那么容易。

即使按照从大到小的递进关系来看，
这几条里看似最简单的一条
“我要成为温柔的强者”也并不简单。

成年人生活并不像学生一样，
会有期中、期末、寒假、暑假这种明显的节点让你自省，
很多人逐渐是靠着惯性活着。
而靠惯性活着就很难做到“有则改之，无则加勉”了。

风口让猪飞了起来，
猪可不能以为自己真能飞。
按我自己的说法，
叫 Stay Awake；
而按电影《辛德勒的名单》的比喻，
会这么说：

“你可以轻而易举地处决一个集中营的人，但这不是权力。
真正的权力，是你把刀架在别人脖子上时，可以说：‘我宽恕你’。
这才是真正的权力。”

结

写到此处，
因为我笔力不足而一分为四的《毕业五年的报告》也终于完工了。
相比于两年前的《毕业三年的报告》，
感觉作者的可爱度下降了(x

这个系列的下一篇，
估计也将是两年后、三年后，
甚至五年后的“毕业十年的报告”了吧。

或者，看到这的你，
其实是五年后通过文内超链接点回来的呢？
嘿嘿。

那最后，祝你身体健康，有缘再见！

（完）

对加速主义保持清晰认知

Thu, 12 Nov 2020 21:44:34 +0800

这屋子太暗，须在这里开一个窗，大家一定不允许的。
但如果你主张拆掉屋顶，他们就会来调和，愿意开窗了。

——鲁迅

鲁迅先生的这句话，
很传神地阐述了一个加速主义的例子。

认识到加速主义的存在

什么是加速主义呢？
加速主义，
就是顺着事物发展方向，
一路不收手地推下去，
直到失去控制。
一般加速主义会在什么情况下出现呢？
不担责的建议决策时。

除了拆屋顶来开窗这个经典例子，
加速主义日常生活中也很常见。

比如年轻男女谈朋友，
遇到些矛盾，
就会有很多围观群众拱火：
“快分手，别谈了！
连生日/国庆节/双十一/圣诞节/冬天来临都不会给你买礼物的肯定不是好伴侣！”
但其实恋爱这种冷暖自知的事情，
真的分手了旁人也不用承担孤独的煎熬，
往往只会留下“快进到分手”这种一句话的狂欢。

又比如像写代码的程序员，
其实可以在项目搭建时，
引入一些自己喜欢的冷门的技术栈（比如 Lisp）。
但承受后果的，
却会是人员离职交接时，
没人能顶上来做业务的公司。
而挂在 GitHub 个人主页的一句 I'm Lisper 也成了此时映照加速主义的最好信条。

当下的群体容易产生加速主义

2020 年的时代思潮下，
自由主义与个人权力意识大量觉醒。
只论个人，
加速主义微不足道，
因为_冷暖自知_。
但在群体的语境下，
总会浮动着加速主义的潮汐。

谦虚是美好的品德，
儒家文化圈中更是。
群体生活中，不自觉地就会出现比这还夸张的行为。
比如前阵子多益公司，
宣布“公司业绩很好，让大家自愿选择降薪”，
然后嘉奖那些主动降薪的人。
这个行为在外部看来是“过于弱智，以至于让人怀疑是否在反串”，
但在内部真正踊跃接受了这个决定的人，
不也会有抱着“一脚油门踩死，毁灭吧”这样的加速主义心态吗？

之所以群体容易产生自由主义，
是因为群体是不需要为结果负全责的。
天花板被拆掉了，
受凉了不只有你，
所谓“天塌了高个子顶着”，
那嚷嚷一下拆天花板又有什么关系呢？

比如像女权男德、政治正确、性自由这样的话题，
每一个在当下的群体语境中其实都充斥着加速主义论点。
正面迎击加速主义，
不如顺着舆论踩一脚油门，
吟一句“生命诚可贵，自由价更高。”

对加速主义保持清晰认知

加速主义是主观的、强烈的、不可抗拒的。
工作生活中，
我经常看到加速主义的身影，
并且我也很多次受着加速主义的影响。

我以前是弹性上班，早上 10:30 左右到即可。
但工程师同事们习惯懒散自由，
一方面这个管理方式过于特别，
另一方面早上客户参观也影响销售情况，
后来公司便讨论改到了 10:00 上班，迟到罚款。
讨论时，基于加速主义思想，
我还加了统计下班时间、引入打卡系统这两个并不弹性的设定。
虽然打卡没打上，
但这样的策略一引入，
早上上班的状态确实焕然一新。

有时顺着事物发展方向用力一推，
确实能得到跟认知并不一样的答案。

还有一个类似的事情，
就是公司的大家一直觉得网络很卡。
因为总带宽低，每个设备都被限了低速。
但后来大家抱怨多了，
便给每个人的限速都开高了。
（此处有加速主义存在）
网络情况却更恶劣了，
因为只要有一个人卡了网速，
他占用别人的部分就会更多。
真正清晰认识到加速主义的办法，
是合理规划流量、网络分片、加高总带宽。

综述

社会上、工作中、生活里少不了要跟群体打交道，
站在 2020 年的这个时代当下，
你会观测发现到处都存在着加速主义。

当你是参与者的时候，
你可以不必迎击加速主义，
而是利用加速主义来表达你的态度；
当你是决策者的时候，
你需要清晰认识到加速主义，
从情绪之中摘出真正的价值，
并与之共事。

这屋子太暗，
有人主张拆掉屋顶，
而你知道，
他其实是想开扇窗。

（完）

一厘米的权力

Wed, 11 Nov 2020 20:53:43 +0800

前阵子跟基友们聊到 S1 发的一张图，
hulucc 感慨：“讲道理这个作者至少占一半锅。”
eagzzycsl 附：“像是一厘米原则，开发有义务保证最终完整性。”

一厘米主权

有一个流传很久的故事，
说还在柏林墙时期的德国，
有一个士兵射杀了一名翻墙逃亡的青年。
因此他被告上了法庭，
虽然他跟律师都辩称“这不过是执行命令”，
但法官指出：
“你确实要执行命令，但你完全可以没打准。”
最终，这个士兵被判了刑。

这个故事虽然听起来很鸡汤，
而且也有一些人质疑故事的真实性，
但是故事里的道理是真切的：
良知是人类普世的原则，
不能因为有借口而降低伦理底线。

这个故事总让我想到《孟子》里的一节，
说梁惠王觉得自己当国王当的尽心尽力了，
能做的都做了。
但孟子直接地指出了当时社会上存在的一系列问题，
并且作下了一个振聋发聩的比喻：

狗彘食人食而不知检，涂有饿莩而不知发；
人死，则曰：“非我也，岁也。”

是何异于刺人而杀之，曰：“非我也，兵也！”

梁惠王在执政过程中，
因为自己的借口能很好地给自己妥协，
但是世道却离他的期望值越来越远。

生活中许多时候是可以依靠着借口得过且过的，
但是到了最终结果时，
还是得看我们具体做了什么。

这就是我所认为的：
可以唯心地思考，
但要唯物地生活。

技术服务业

一厘米主权似乎是一个很遥远的故事，
我再讲一个我记了好一阵的回忆。

大学时候在学校网管部，
每周都要值班报修。
我印象最深的，
是一个因为没选上课而上门吵闹了半小时的同学。

确实，没选上课跟我们负责修网口的网管部同学们有什么关系呢？
但从他本人的角度来说，
除去发泄情绪的因素外，
难用的选课系统跟蹩脚的网络，
大概也是需要解决的。

做技术也是如此。
我见过不少人在合作中，
都会以“我不管这个”的道理来解决他的问题。
而这样的人一多，
就会自然地形成足球场的感觉，
假如每天只在追逐这不能被解决的足球般的问题，
那人的热情就会被很快地耗光。

技术工作里，
在被定义好的工作范畴中间，
就会有这么一些灰色的、偏向于服务的事情，
需要被完成。

我没错

一厘米主权故事里，
还有一个隐藏的信念，
叫“我没错”。

就像头图里的那位开发，
讲道理，他是可以认为自己没有错。
不过假如是我，
我不会这么做。

技术工作因为它的专业性，
所以讲出来的话很难被外行质疑。
就比如我告诉产品：
“这个功能历史实现逻辑就是这样的。”
他很难能亲自读代码来验证我说的话。
但假如我是厨师，我说：“这道菜就是这么做的。”
显然就有被质疑的空间。

技术工作里，
随着工作范畴的固化，
每个人能获得的借口也越多。
但正是这种时候，
才显示出一厘米主权这样，
谦逊、自省这种品质的宝贵了。

所以不论任何时候，都要记住：
人的边界，并不是被划定的，
我永远拥有多一厘米的权力。
（冬泳大叔语气）

（完）

神通中学二三事

Mon, 31 Aug 2020 19:45:02 +0800

我的几个好友里，
灰灰当了语文老师，
佳佳当了英语老师，
而我成为了饭堂阿姨，
我们都有美好的未来。

（一）

不知何年何月，
神通中学成立了。
“为了一个伟大的目标，
让天下的同学都有书读！”
奠基典礼上校长这么说道。
为了这个不知何年何月但光芒万丈的目标，
学校从五湖四海招来了一批师资很不错的老师，
也在市内选拔了一批底子很不错的学生。

（二）

敏俊是神通中学的保安。
因为保安厅就在入口的“神通中学”四个金色大字旁边，
很多同学都把他漫溢的笑容跟“神通中学”等同在了一起。
以至于很多毕业的同学回来参加毕业典礼，
总会问道：“咱们那个爱笑的保安去哪了？”

其实学校也没有什么安全问题，
所以作为一个壮实的保安，
敏俊总是需要时不时干各种杂活。
比如文艺晚会搬投影仪啦、
科技界组织操场上的水火箭比赛啦、
艺术节当油画模特啦等等等等。

因为性格好，大家也喜欢开他玩笑。
比如什么“你小熊饼干呢？”
“食堂阿姨好像特别喜欢你啊！”
“你这么帅怎么不去当偶像练习生~”
每次别人这么调侃敏俊，
他也只是笑着做好一个保安该做好的事情。

（三）

神通中学的政治老师是冰冰，
他也是政治科的科组长，
四十多岁的冰冰有着跟稳重的外表完全不一的内心。

虽然每次备课的时候他都认真教育年轻老师，
但他自己讲课的时候经常是脚踩西瓜皮——讲到哪里算哪里，
尤其是他讲法律的时候。
会考以后讲卷子的课，三分钟就把哲学、社会的部分给评完了，
剩下四十二分钟都在讲法律的题。
同学们也喜欢听他讲课，
还有同学从小道消息打听到他以前跟罗翔同学过一段时间。

不过有一点就是他喜欢拖堂，
这个教导主任拿他也没办法。
他也总会把这句话挂在嘴边：
“现在拖堂是拖你们十分钟，但你们认真听的话，你们一辈子都会受用的！”
也算是苦口婆心了。

（四）

因为原来的地理老师海寒考上了牛津的研究生，
所以去年学校招了个应届生从实习做起。
新来的实习老师是四川来的，叫梦琴，
第一天到级部还给每个人都带了一包兔头，
连看门的保安都有一份。

梦琴有一个很明显的缺点，
跟一个很明显的优点。
缺点是她虽然是地理系毕业的，
但对中国地理不太熟悉，
一次在上课时讲出“辽宁的首都是不是吉林啊”的话以后哄堂大笑。
导致她来了以后，海寒老师更忙了：
不仅要帮学生补课还要帮梦琴补课。

优点就更明显了，
有她在的地方就不会缺少笑声，
大家都很喜欢她。
在她来了神通中学以后，
每学期的“你最喜欢的老师”匿名评选中，
梦琴总是能稳居前三名。

不过这也可能是因为梦琴老师从来不拖堂，
大概也许是因为她想早点去吃饭吧。

（五）

神通中学最开始占地面积挺小的，
后来扩建以后有了自己的饭堂，
搬校区以后饭堂又重建了几次。
虽然饭堂换了几个地方，
但饭堂阿姨一直没有换过，
一直就是同学口中“胖胖的布达阿姨”。

布达阿姨是那种刀子嘴豆腐心的人。
每次有同学在饭堂要关门前踩点吃饭了，
布达阿姨都是一边说着“饭没啦饭没啦，不早点来”
一边把收拾好的饭盆又拿了一个出来打饭。

布达阿姨最享受的时光，
是“熊孩子们”吃完饭以后，
她给自己也打一盆饭，
坐在饭堂的一角，
跟其它学校后勤部门的同事聊聊天谈谈八卦。

不过最近她在苦恼着要不要自己带饭，
因为后厨做饭油盐给的很重，
她既想自己做饭吃得清淡一点，
又不想每天做饭麻烦自己。

（六）

关于饭堂阿姨的千古话题，
就是她们对饭勺的精妙控制。
经常是一勺美满姻缘，
一抖红尘再见。

在大家都埋怨饭堂的饭越来越少的时候，
保安敏俊倒是不觉得：
“没有啊，我感觉饭还挺多的？”

后来吃饭时后勤部聊天，
布达阿姨邪魅一笑，
用耐克弯钩般的嘴角上扬揭露了秘密。
原来布达阿姨了解到，
敏俊其实高中毕业就出来打工了，
今年年初的疫情让温州的他现金流接近断裂，
敏俊已经啃了好几个月的馒头了。
于是布达阿姨就会在敏俊来吃饭的时候，
偷偷地给他加点饭，
米饭加一两，狮子多个头。

管后勤的晓俊听完直感慨：
“虽然学校里面无大事，
但是小事你用真情做，
也是能做出很大影响的啊！”
管财务的关口（晓俊死对头）马上不留情面地评论道：
“陈晓俊你又乱说了！”

（七）

其实学校里还有很多微不足道的小事，
比如爱画画的美术老师重音与爱摄影的留级生几龙碰撞出的火花啦，
比如明明是副科老师但是呆学校时间比班主任还久的通用技术老师志强啦，
还有班长钉钉子跟副班长带带子之间的互怼啦。

不过毕竟这篇小文章只是讲学校的二三事，
而并不是一本完备的校史。
就算是完备的校史，
那也只是过去的辉煌。
学校的未来，
依然是依靠每一个学生、每一个老师去书写的。

不知何年何月，
神通中学成立了。

（完）

毕业五年的报告之技术

Sun, 12 Jul 2020 23:45:58 +0800

16年接触了 Web 整套技术栈的我，
决定在这条路上不断攀爬，
直到找到我技术上的天花板。
当时我写了一篇《后端工程师技能树》。

现在回过头再看，
我并没有按照叶子节点的顺序去一步步做。
除了系统地学习了解技术知识以外，
我更多是在“明天上线”以及“线上挂了”的血与火的泥泊里扑腾。

这篇就以不同的视角，
记录一下我这几年技术上的感悟吧。
由于讲述的更偏 Web，
所以本篇基本都是以再惠的实际开发为例。

项目、语言与框架

16年的时候，公司的业务在一个大主站里就可以完全解决了。
这单个项目不仅包括了全部后端代码，
还包括了全部前端代码（不过后来前端就拆出去了）

当时用的是 Python 2.7 + Django 1.8,
不过由于 Python2 在生命的末期，
后来我们就找了个周末升级到了 Python 3.5。
顺带一提，当时不升 Python 3.6 的原因是 Ubuntu 16 默认带的是 Python 3.5。

Python 是一门非常容易上手的语言，
我进再惠前其实没有认真用过（连 virtualenv 都不知道是什么，只会 print），
但很快就可以开始参与业务开发了。
整个主站在开发周期里，
框架没有大的变动，
基本上是前人怎么写的，后人就怎么写。

当时我在语言上感兴趣的几个点，主要包括：

magic method 与元编程：于是我实现了一套根据配置生成接口的逻辑
性能、并发与处理能力：于是我们经常在小黑板上画各类网络架构图
不同框架之间的对比：于是我们内部后面的项目尝试使用了 flask/tornado 等各类框架
关于语言本身的话题：于是我们内部每天都在讨论垠神@wangyin 的博客（x

后来业务线逐渐开始变多，
我也有机会从零开始搭建一个项目。
因为是从零开始，所以我心中暗想：
“以前很多东西我都是知其然不知其所以然，
这次项目的所有方面我都要完全理解才行。”
于是那个月所有的业余时间我都在读各种文档…

不读不知道，一读吓一跳。
我发现我以前默认的很多习惯用法，
其实都有更佳的实践：

轻度使用：
以前项目里会搭配着使用 djangorestframework,
但我们从来都是手写各种序列化类，
并没有使用框架自带的 django model 支持。
而且我们自己实现了一套 schema 验证系统，
既没有用 djangorestframework,
也没有用 marshmellow 这样的库。
（这导致了后面支持 swagger 非常困难）
缺少检查：
Python 社区中有非常多的检查工具，
但我们只用到了最基础的 flake8 来验证 PEP8 风格。
我们在合作编程中，
因为每个人 PyCharm 配置的不一样，
解了无数次 import 的冲突。
（更别提还有数组末行加逗号的冲突了）
版本老旧：
我们用的很多三方库一直保持着版本更新，
但我们却一直用着旧的版本（更别说语言本身了，f-string 我们也是老后面才用上的）

这些问题在后面的项目开发中，
我逐个都解决掉了。
轻度使用的问题好说，找一个哥去研究正确的用法然后去优化就行了。
（有时这个优化会涉及几百个文件，所以需要一个 vim 用的溜的哥）
缺少检查也好说，像 flake8/isort/pytest/pylint/yapf/black 我们都尝试使用过，
后面按照项目规模我们开了不同级别的检查，
原则上，项目越大检查越严格。
关于语言与三方库版本的问题，
我每周基本都会保持跟社区的更新，
以人肉 dependency bot 的方式去维护代码。
在解决完这些明显的问题后，
19年我很开心地跟伙伴们感慨过：
“我很有信心说，我们写的这个项目就算放在开源社区也是一流的。”

框架上最终我们还是大规模使用了 Django，
因为 Django 的整套 ORM 实在是对增删改查这样的业务太契合了。
性能上我们后面尝试并最终使用了 gevent，
让整个项目写起来体验一致，
跑起来性能合格。

现在要我实现一个标准的 Python Web 服务的话，我会考虑使用这样的技术组合：

使用最新的版本号，比如 Python3.8+/Django3+/Celery4.5+ 等
在 CI 中开启一系列标准检查，比如 flake8/isort/pytest/black
使用 gnumake/pipenv/drf-yasg 这样的工具链
使用 gunicorn+gevent 作为运营环境
在语言的性能问题成为了关键问题时，考虑使用 golang 重写关键部分（不过一般此时都要更大程度上更新架构了）

平台

过去几年的技术生涯里，
我最主要跟两个平台在打交道：
一个是云平台 (AWS/Aliyun/Azure)，
另一个是业务平台（微信开放平台）。

业务平台没什么特别好说的，
因为我做的整块业务都是基于微信生态的，
所以对开放平台、小程序、OpenID/UnionID、支付回调这么一套非常熟悉。

最早接触的云平台是 AWS(China)，
我觉得云平台最好的一点是运维扁平化。
招人的时候我会跟候选人说，
我们这个职位从网络、业务、数据到部署、监控都要接触。
而能做到这一点的基础，
就是我们“去运维化”地让大家直接去对接云平台
（有些地方可能会简单包一层）。

最早我们用的是 AWS（国服），
相比于国际服，国服用户缺少了一些非常基础的设施
（比如像 ACM/Route53 等）
导致不论是像 zappa 这种跑 serveless 的库，
还是 AWS EKS 这种更高阶的服务能力都是缺失的。
在18年底我司就从 AWS 切换到了 aliyun。
其实整体的架构没有本质上的差别，
感受上阿里云的服务的确好些，
不过按 @lxkaka 的说法也可以叫：
“他们这个系统假如没地方问的话说不过去啊！”

目前我们使用云平台的姿势包括：

最基础的开机器、负载均衡、域名一系列
数据相关的 MySQL/Redis/Mongo/EMR 一套
监控报警日志相关系统
全套托管的 K8S

随着对云平台使用的更加深入，
跟云平台强绑定的技术也会越来越多，
比如像日志系统就基本抛弃了 ELK 拥抱了阿里的日志。
但从成本的视角上看，
对工具的使用减少了冗余的运维需求，
一定程度上是解放了工程师的时间与效能。

现在要我从头开始搭建云平台的基建的话，我会考虑这样的实现组合：

拆分 VPC 网段，大部分情况分生产、测试、访客三个网段就可以了（并辅以合适的安全组策略）
以托管的 K8S 服务为核心搭建业务系统，配上配套基建（云盘、日志、监控等）
用 LB/Gateway 约束网络入口、出口，拆分各网段之间流量，尽量减少网络上的损耗
选型时优先考虑云原生功能，如 MySQL/ES/MQ 等

部署

在大主站时期，
我们的 Python 服务以 supervisor+virtualenv 裸部署在三种机器上：

Web: nginx+uwsgi+django
Worker: celery worker
Cron: celery beat

此时的更新代码是用 fabric 直接连入机器 git pull + supervisorctl restart 二连。

这样的问题是无缝发版（蓝绿部署）是需要自己手动实现，
比如我们最早实现了一套基于 AWS LB 的动态添加、摘除节点的逻辑。
这部分逻辑称不上优雅，
也需要自己维护。
而且这么做对机器环境有着强依赖，
在前文的升级 Python 版本中，
我们也需要一并进行系统级别的升级。

不过后来很快我们就进行了全站的 docker 化，
并有过一段短暂的基于 docker network 的无缝发版实现。
此时的部署换成了 docker pull + docker(compose) restart。
整条技术链路中我们摘掉了 supervisor/fabric/system 相关的依赖。

伴随着平台从 AWS 迁移到 aliyun，
我们大部分服务也上了 K8S。
部署也从上机器部署升级到了 k8s 相关的部署工具链。

大部分情况项目里用的是手写的 envsubst + kubectl，
不过 kubectl 对版本的支持非常有限，
所以很多时候我们也会附带使用 kustomize。
helm chart 而言对业务系统提供了多余的版本控制功能
（我们一般在线上不会同时跑很多个版本，
往往只会保留最新版跟灰度版）。
但 kustomize 也仅在输出部署文件上做的比较好，
在展示部署进度上并没有特别的功能，
而且很多时候会在项目里漏一大堆的 configmap…
所以到目前，我们不少项目都使用了 kapp 进行部署。

而在构建上，我们从最早的 Jenkins CI 全线迁移到了 GitLab CI。
除了集成单元测试、体验版自动更新、灰度发布这些核心流程以外，
我们还深度尝试了许多 GitLab CI 提供的工具集成。
比如像 kaniko/minio+artifacts/gitlab+sentry 等系列自动集成自动部署的工具基本我们都用到了。

时至今日，我考虑新起的一个 Python 服务会包括以下的技术组合：

核心部署流程基于 K8S，生产测试使用相同的配置，以 namespace 区分不同组的业务
不采用 helm, 而是使用 kubectl+kustomize+kapp 的方式完成部署
以合适的姿势起新三样：
- 对于 HTTP/RESTful 服务, Web 上使用 gunicorn+django (uwsgi 年久失修了)
- 对于内部的 gRPC 调用服务，使用内部的 djangrpc 实现 (基于 django，支持一套代码起 http+grpc)
- 对于异步任务，就是简单的 celery 走起
对于以上提到的服务，部署中考虑完整的向前兼容、按流量/用户的灰度、标准的监控日志报警的搭建

架构

早期我们的网络拓扑相对简单，
流量的路线是 外部 ==> aws elb ==> nginx+uwsgi+django(单台机器)，
我们仅在整条链路上做了少数配置，
比如在 aws elb 上配置 https 的处理，
在机器上做了简单的日志收集。

而现在我们的网络拓扑有多种路径，
以其中相对标准的阿里云上托管的 K8S Web 服务为例：
外部 ==> ali slb ==> k8s ingress ==> nginx ==> gunicorn+django.
可以比较发现除了 k8s ingress 层外，
nginx 层也被单独拆分了出来。
这样的网络拓扑我们对其的控制粒度更加精细，
不仅可以在每一层单独处理 IP/流量/日志/行为等逻辑，
而且每一层也都是可拆卸可更换的。
比如目前我们的集群中，
就有使用到 nginx-ingress-controller 的，
也有使用 kong-ingress-controller 的。

而在整体的服务架构上，
我们拆分了三层的服务。
顶层是 Web 层，这些服务主要对外部提供服务，走的主要是公网流量的 RESTful 调用；
中间是 Service 层，这些服务主要对内部提供服务，走的主要是内网流量的 RESTful/gRPC 调用
（我们正在使用 gRPC 逐步替换内网 RESTful）；
底层是 Tool 层，包括了一系列我们维护的中间件、工具服务或者是包了一层的云原生服务。

以我现在的认识，在一个中型规模的技术团队（100人规模），我会采取这样的架构技术组合：

以网络为边界拆分内外部流量，外部使用 RESTful HTTP 调用，内部使用 gRPC 调用
在业务合适的情况下，使用比如类似 Kong 这样的技术作为网关，处理鉴权、灰度、分流等系列逻辑
内部服务之间不限制选型（前提是做好人员梯度培养），但要划分清晰的服务边界，进行合适的分层
区分不同层服务的级别，以定义好稳定性要求、创新余地与网络拓扑

协作

团队协作的核心，就是人跟人的交流。

因为业务线相对较多，我们基本上是以 two pizza team 的粒度来拆分团队的
（two pizza team 的意思就是点外卖时，两份披萨可以让整个团队吃饱）
每个相对较小的团队会负责数个独立的服务，
组内成员互为 backup、互相学习、共同成长。

最早我们的 git 开发流是基于 commit diff 的，
换句话说只要你的改动是正确的，
那基本就可以合并进主干分支了。
——不过我们很快尝到了苦头（这个很快≈三年）
一些老的代码因为当时的产品也没有留下成建制的 PRD，
而且我们公司做的是B端产品，逻辑有时又巨特么合理的绕，
导致后人在 blame history 时，
经常需要去分析这究竟是 bug 还是 feature。

到目前，我们整个团队（强行被）达成了一致，
使用的是“一个 PR 只有一个 Commit 只做一件事情”的基于 rebase 的协作流，
我们这样产出了接近于线性的完美 git 历史。

而另一方面，关于版本控制我们基于 git tag 使用了内部的小机器人来管理。
因为我们不需要考虑旧版本的兼容维护问题，
所以大部分情况我们用的是日期化的格式 (v2020.07.01)。
基于 git tag 我们又跟 sentry-release/ticket-system 做了一系列的工具链，
包括自动生成版本之间的 changelog，
自动对每个版本的发布内容进行归类分析等。

整套使用 git rebase 开发，使用 git tag 发布的协作机制让我们获益不少。
而为了达到这样的效果，我们在团队内部达成了这样的约定：

认知上，项目以 rebase 为开发基础
- 没有什么“我不会用 git”的接口，不会可以学。
- 个人当然可以喜欢 merge，那请在个人项目里用，团队项目大家统一规范
行动上，就做到我们设想的那样好
- 每个 PR 只包含一个 Commit，每个 Commit 只修改一类内容
- 提了 PR 就求 Code Review, Review 了就留评论，评论改完了就合并，不拖泥带水
工具上，我们需要有个哥来解决协作工具完善的问题
- 我们优化了 Pipeline 的速度，跑完 97% 覆盖率的单元测试+所有检查只要 3 分钟左右
- 针对线性历史，我们提供了一系列发版、合并、变动检测的机器人助手功能

除了基于 git 的整套开发流，
我们还共同维护着一整个新手村任务（在以前的文章里有讲过），
而且我们推行的 Buddy 制度会让一个有经验的同学完全手把手地带新人
（不过这个具体要看每个人用心的程度了）

总结

回过头看，这几年参与的技术讨论、选型、命名、开发、协作、复盘都历历在目。
了解的技术越多，我就越觉得技术世界的广博与好玩。
其实做技术就像玩游戏一样，本质上都是打怪升级穿装备。
本文里讲的，也可能只是我在这世界的一隅，提笔能想起来的一些只言碎语。

但假如我要把整篇文章都删掉，
只能留下一句话。
那我会毫不犹豫地留下这句话：

不会可以学

（未完待续）

毕业五年的报告之团队

Mon, 06 Jul 2020 23:45:13 +0800

从17年底负责一整个团队开始，
一直到今天，
我都保持着 Dev + Leader 的双重角色。

（起）

上篇主要是流水账地记录了一下我零碎的回忆，
这篇报告我想系统地整理一下我与团队相处的方法论。（或者说团队文化）
我总想着以后有机会，
可以去开辟一方属于我自己的土地，
那时的我或许也会这么去创建、带领、组织团队吧。

谨记目标 - Always Aiming

我很喜欢辩证法里关于矛盾的这种观点：
矛盾有主次之分，很多时候抓住解决了主要矛盾，
其它次要矛盾也会迎刃而解。

举个栗子，
工程师在团队协作流中发挥的作用是我很关注的一个话题。
同样一个工程师，他主动去工作与被动地接锅，效果差别是很大的。
所以每次在协作中，
我都会尽可能地提醒每一个伙伴，
用户最需要的点在哪、业务的目标是什么、谁需要做什么事情。
大型项目尤其需要这样的校准。
很多技术上的难题，或是产品上看起来绝妙的方案，
可能放在目标上都不值一提。

在连连团开发初期，
我们自己写了一个毒液系统，
提供了一整套实时的数据展示，
让开发、产品、运营都能很方便地解决自己的困惑。
后来整套系统用开源的 metabase 重构了一遍，
演变成了现在的蓝冰内部数据总览，
时刻用量化的数字瞄准着目标。

同样的道理，
放到成员的成长计划也是一样的道理。

我的团队招人的目标是什么？
是干活解决业务目标吗？
是的。（笑）
但不仅限于此。（严肃）
在过去的实践中，
团队的成长不仅源于上篇报告里聊到的招聘理念：

坚持只招优秀的人，不会可以学。

还源于团队每一个成员与公司的共同成长。
假如团队只有招聘标准，没有成长计划，
那么入职即巅峰。

幸运的是，在过去几年里，
有很多优秀的同学刚毕业就来了再惠。
除了技术上的成长，
我也会特别关注他们薪资上的涨幅。
我觉得大部分人都是从刚毕业的窘迫中走出来的，
只要努力去提供一个适合飞翔的环境，
我们都可以起飞。

在这几年的团队成长计划中，
我帮过性格内敛默默贡献的同学争取了（特批的）升职加薪，
也设立了固定的内部沟通与分享机制，
还尝试过不定期的《人类补完》邮件计划给团队同步公司级的目标。

对我而言，团队协作里首先让我想到的方法论就是谨记目标，
做任何事情都去想办法抓住主要矛盾。

快乐协作 - Keep Laughing

前面好像过于严肃了，让我们快乐一下。
这是我脑海中经常蹦出来的一句话。
工程师里也会流传这么一句都市传说：
人生苦短，我用 Python。

一个快乐的轻松的环境，
对事情协作，或者是工程师这种脑力工作者有着非常大的效率提升。
而且因为工作在里面占的比例非常大，
一个充满欢笑的工作也更能激发大家的热情，
或者更狭窄地只说我自己的想法：
我喜欢充满笑声的团队。

我们给帮我们提醒 PR 的小机器人加上了昵称功能，
可能记录着三年前一个同事刚入职时绰号的由来；
研发跟产品也会在对需求之外的时间互怼
（表面上针锋相对其实就是打情骂俏.jpg）；
我们也保持着微信群的非工作消息活跃，
各类烂梗破图无穷尽。

对应的，快乐的环境是需要相对宽松的制度的。
假如团队由是严苛的赏罚、强制的高压、强行统一的思想构成的，
那团队也是很难长出快乐的小花。

更进一步，
快乐的氛围会让大家发展出工作之外的友情，
而友情会让团队更加紧密、更加团结。

都是朋友 - Make Friends

我跟 @hulucc 都组织过网游的公会，
一次夜聊时，我讲到了我关于网游公会稳定的观点：

假如一个组织是层级制的，
那这个组织的关键节点就是脆弱的。
比如我见过不少公会是会长跟核心玩家 AFK 以后就凉了的。
想让组织变得稳定跟可发展，
那么这个组织就得是网状的，
这样每一环都是可以缺失的，
同时每一环也都是非常重要的。

而构建网状组织的方法很简单：友情。

我在的团队里，我不一定跟每个人都保持着很好的关系。
但是我会关注每一个人有没有在组织里找到至少一个好朋友，
并且我还会有意在分工时，让好友们做一块项目。
他们的友情就会在并肩战斗中得到炮火的磨练。

友情构建的网状组织，
从团队的角度来说，更加稳定、效率更高、沟通更省力；
从个人的角度来说，收获了一份互相理解、能交予后背的件事友谊。
很多从我司毕业的同事，至今也跟他们的好友们保持着联系，
这些跟他们在工作里学到的技术一样，
都会是大家一辈子的美好回忆与珍贵财富。

在实际的协作中，Make Friends 与 Keep Laughing 这两条原则相辅相成。
有不少人跟我说过羡慕我们团队的文化跟精神面貌，
但让我更开心的是看到大家在工作上有所成长，
在工作以外的人生中也遇到知音。

交换信任 - Spread Trust

在团队整体的良好氛围里，
交换信任就是一个显而易见的方法论了。
交换信任不仅意味着信任某一个同学，
还意味着信任着团队这个整体。

我们在内部的权限、任务认领、发言机制上都给予了每个人最大的信任。
比如我们日常敏捷开发时，
只要举手说“我想/我不想做这个”，
Scrum Master 就会修改对应的分工。
甚至只要举手说“我想做 Scrum Master”就可以当上 Scrum Master
（然后成为工具人）

对于工程师关心的技术话题也是如此，
我们从不固化某个事情。
新同学接手项目的时候，
我也会反复说明：
“不管你觉得项目里任何地方看不懂或者不科学，
都随时提出来，我们一起想想办法。”

还有相对特殊的一点是，
我在团队里并没有维持固定的 one-one（一对一单独沟通）机制。
不论是大事小事、业务技术、个人发展、
传统意义上合适或不合适单独沟通的内容，
我们都会在固定的周会上跟全团队一起同步这个消息。

Spread Trust 的方法实践下来，
最直观能感受到的一点是团队里大家的安全感都很高，
培养出了非常多有 ownership（主人翁意识）的伙伴。
因为信任，团队工作不会有后顾之忧，
大家就可以一起保持 Always Aiming。

就像《珍珠鸟》里讲的一样：

信赖，往往会创造出美好的境界。

保持清醒 - Stay Awake

很多都市传说里说新人进公司会有蜜月期。
撇去这个说法的准确性，
的确很多时候工作会上头，
认真的同事认真工作的时候就更加容易上头。

这时候就需要有“众人皆醉我独醒”的气质了，
Stay Awake。

举些例子。

团队里吵起来的时候，
需要分辨是因为观点吵起来的还是因为沟通吵起来的，
看情况打断这个沟通。

在做一件看起来百分百有把握的事情的时候，
一方面鼓励并肯定团队，
另一方面做好塞翁失马结果让子弹飞一会儿的准备。

在团队发生变动大家陷入迷茫的时候，
去了解最全面的信息，
用积极的想法、活跃的态度去影响团队。

大部分时候，团队工作是多元的复杂的，很难片面地去评价；
但个人、尤其是群体，总会倾向于非黑即白的二元论。
这种时候团队里就需要有个哥站出来，
给大家展示现实里这张纸的另一面——另一种可能性。
即使这张纸或许是莫比乌斯环。

Stay Awake 的思考时常让我感受到自己跟团队的撕裂，
但如此的思辨，是的确能对团队整体有很大帮助的。

永无止境 - Never Stop

随着时间的翻滚，历史的进程轰轰作响。
团队作为一个整体，达到的里程碑会不断增加。
我们平常接触的事情，往往是有一个固定的终点的。
比如电影会有一个结尾，
项目会有一个上线时间，
每年会有一次述职。

但在我信奉的这套方法论里，
团队的锻造、成长、发展是没有止境的，
在团队里的个体也一样。
我会每天跟自己说：你很棒。
但我从不会跟自己说：你足够棒了。

即使这几年我很多时间需要花在管理的事务里，
我也一直一头栽在开发的第一线。
我也给自己加上这个思想钢印：
我希望我是团队里技术力最强的，
假如我不是的话，
那样就更好了，
意味着有其他哥的天赋乘以努力居然超过我了。

我会与公司之外的同行、朋友们交流，
去横向学习如何能更好地发展进化团队；
我也会像今天一样停下来想一想，
我所在的团队在过去几年之间的演化之路。

不论是团队还是个人，
我们都走着一条永无止境的修行之路，
与时间为伴，与时间为友。

（结）

从17年第一次团队开周例会的时候，
我跟大家分享了我关于个人奋斗的感悟。

一个人的成长并不是孤立的线性，
而是多因子的乘法原则，
让我们写成公式就是：

成长 = 个人 x 团队 x 公司 x 社会 x 历史进程

当我们想获得更多的成长时，
不仅要考虑个人的奋斗、团队的进步、公司的壮大、社会的发展，
也要考虑历史的进程。

当我在兼顾个人的奋斗之外，
还想做出更大的贡献时，
我就会努力推动团队的进步、公司的壮大、社会的发展。
有朝一日若是有幸，
我也希望能参与到历史的进程，
并骄傲地说出那句：

苟利国家生死以，
岂因祸福避趋之。

（完）

毕业五年的报告之回忆

Sun, 05 Jul 2020 21:46:03 +0800

这周末去安吉吃了烧烤。
里脊肉需要反复被刷油，
最终它才会散发出迷人的香味。
人的记忆也是如此。

（起）

在两年前我写了一篇万字长文《毕业三年的报告》
我看着两年前写下的文字，
仿佛眼前是两年前的紫月给我讲着他当时的心境。
末了，他还跟我说：
当你五年级的时候，
记得要写一篇《毕业五年的报告》。

这篇文章记录了我一些并不靠谱的回忆，
纯粹个人感想，没有借鉴意义。

（一）终身学习

在 QAD 时，我并不了解很多 Web 知识，
比如像 RESTful 这样的概念我就不甚了解。
当时系统要接入 Jira RESTful API,
这个事情分给了队友 Raymond 做，
后来他赴美读书，事情就交接给我了。
我头疼地想：“接这个锅还要特别学一下 RESTful，
这个以后不知道有没有用。
还不如认真学学 sudo 权限组拆分，
这个可能对业务有用。”
于是交接时我就没认真看 raymond 的代码，
结果他写的代码运行的异常稳定，
到我从 QAD 毕业后我也没有被迫学 RESTful 的借口。
直到后来，
我才知道 RESTful 这个概念是如此的基础跟重要。

后来我在工作里遇到了很多这样的事情：
有时不得不学习一些“我以为很临时”的事情，
这些事情甚至不一定是技术方面的：
比如微信迁移公众号是可以顺带迁移 openid 的；
比如A支付渠道退款是24小时，但B支付渠道退款是7天；
比如点菜机是有临时开桌、合并桌台的特殊操作的。

现在回过头确认，我很认可“认真对待每一个知识”的态度。
对于像 Vim 这样普世的技术，
我会非常有信心地安利给身边每一个人：
这是你学了就一辈子受益的技术。
对于像 Jira 某个接口这样特定的知识，
我会把它存在心里，织成一张大的知识图谱。

这串回忆给我留下的印记是：
摒弃实用主义，
保持终身学习。

（二）海绵宝宝

2016年11月28日是再惠录取我的第一天，
前一天，11月27日，我跟 Mia 一起搬家到了塘桥。
因为徒手搬了两个人三十多个箱子上下六楼，
入职第一周我光荣感冒了，
到了周末感冒没好的我，
跟着公司去了某个度假村开了次全员年会，
并与室友 @huangzilong 聊了很多有的没的。

当时的我就像《三年报告》里写的那样：

我那阵子每天回家都跟女朋友说：
“我好菜啊，队友好强啊，
但我真的好开心啊，感觉啥都能学到，
而且他们下班也会写代码，
感觉找到同类了啊，不过感觉再也追不上他们了啊”

我能感受到把自己丢到一个新环境的时候，
就像把海绵丢到水里，
短时间内我能吸收大量信息。
而且更令我开心的是，
即使是我眼中技术力已经很强的伙伴，
他们也依然是海绵宝宝，
吸收着外部的信息与知识。
我始终记得靖哥哥当时讲过的一句话：
“我们其实也是全栈，只不过不是职能全栈，而是业务全栈。”

在一个相对较小的团队里（20人），
我们以前端、后端这样的角色区分了工程师，
但是每个后端从网络数据库部署这样的基础素质、
到支付营销微信这样的业务知识都会努力去做到完全了解。

俗话说“三人行，必有我师焉”，
越广阔，就意味着要学习的越多。
所以大家一起，也都成为了会输出想学习能吸收的海绵宝宝。

这串回忆给我留下的印记是：
做一个广博的海绵宝宝。

（三）爱与陪伴

公司每周上班五天，早的时候我九点能到家，
每次在沙发上坐下来以后，我都会问 Mia: “今天学校里都有什么事情呀？”
然后我们就会讨论一番工作、八卦、人生，非常让我放松。

公司不打卡，所以偶尔我也会加速清理完一天的事情，
晚上七点就跑去跟 Mia 约会，
其实就是在大众点评上找能吃得起的看起来不错的店挨个吃过去。
有时吃到用我司产品的餐厅，
我会很兴奋地跟 Mia 讲：“快来试试支付，看有没有服务器出错啦”

还有很多个夜晚，
我在房间盯着黑色的屏幕写文章/发版，
Mia 在隔壁已经沉沉睡去；
第二天早上我醒来时，
上班时间比我早一个小时的 Mia 已经出门了。
我们也会开玩笑，说这种工作日我们就是互相暗恋但是互不相见的室友。

后来一次跟 @lvxinyan 聊天时，
他问我对自己的工作有什么想法。
我想了想，说：
你应当找一个女朋友。

假如人生是电影，你就是主角。
假如你是主角，你就会经历起承转合。
可能会有这么一天，你从工作回家，
心里非常沮丧，觉得整片天空都是灰色的。
但此时一个可爱温柔美丽亲近的美少女问你：
“今天学校里都有什么事情呀？”
你就不会被这片单薄的灰色天空影响。
到了明天，依然晴天。

这串回忆给我留下的印记是：
多跟喜欢的人呆在一起。

（四）招聘理念

我是被 @ldsink 内推进来的，
后面我也推荐了几个朋友来我司逛逛/面试，
大家的一致好评是：你们公司好多美少女啊！
尤其是前台、设计跟 HR 得到了非常多的赞扬与仰慕，
但是好看的同事，好像并不影响我们很难招人这个事实。

当时写了一篇《HR就讨厌我们这样的技术，今年一个offer都没发》
后面我还专门统计过当时的面试数据，
看了 200 封简历，最终才招到了 2 个工程师。
后来 HR 严厉警告：上海的 Python 工程师简历池已经快被击穿了！
于是趁着业务发展，我司引入了 Java 技术栈，
后来更是有华哥跟海兵把控全局，整个招聘节奏才是缓了下来。

我进再惠的第一周就被拉去当面试官了，
靠着大学在 NIMO 锻炼的经历我非常顺畅地面了下来，
遇到过面试刚开始就丢逼走人的，
也遇到过面试完成为了好朋友的。

18年我独立负责组一个团队的时候，
我就在想，究竟怎样才能尽可能地做好。
然后脑海中就复现了那个经典的思想实验：
忒修斯之船。

@luyu 说过一个观点，
对于互联网的产研同事，
三年左右跳槽是很常见的现象。
虽然我不喜欢这样的设定，
但一个组织的确会面临忒修斯之船这样的困惑。

后来在一次跟 @hulucc 的聊天中，
我得到了心里的答案：
顶级人才构建顶级组织，
次级人才构建更次级组织。
但假如我现在还很弱小怎么办？
很简单，不会可以学。

所以后来我面试的方法论就从以前期望的“只招优秀且对口的候选人”，
变成了“只招优秀的候选人”。
并且在后面的实践中，
我确认了这条是可行且让我自己、让团队能变得更好的实践。
后来有同学私下跟我说，
他觉得团队有种“独特又干净的理想主义气质”，
他很喜欢。

这串回忆给我留下的印记是：
坚持只招优秀的人，
不会可以学。

（五）长期价值

谢老板退居二线以后，
再惠又一次邀请华哥来当 CTO。
在还没最终确定前，拉总跟我一起去参加了华哥的饭局，
这种提前认识潜在 Leader 的感觉是挺奇妙忐忑的。

后来18~19年我们在刷完业务所有需求之外，
整体完成了云平台级别的迁移、架构级别的安全升级、授权统一的项目。
我最认同的一点是持续为长远的价值投资。

因为餐饮行业的服务业属性，
产研在整个链路中是处在中后台提供解决方案跟工具的。
很容易就变成“办公室做题家”，
业务方给一道题就做一道题。
长远看来别说业务全栈了，
连技术本身也会被懈怠，
并不会去更新、改进、朝着更高更好的方向去变革。

这种时候我司里常会念叨一句话：
“需要有个哥想想办法。”
于是可能在某个周末，某个深夜，
或者是某个早早做完事情的时候，
就会有一个饱含智慧与研究耗时的 PR 被提了出来。

这串回忆给我留下的印记是：
每一天都发起变革，
持续地投资长期价值。

（六）输入输出

之前跟卡布达玩成语接龙，
卡布达一连接了三个成语并给快乐的我贴上了这样的标签：
神神叨叨、叨叨逼逼、逼逼赖赖

而我想到的是钱钟书在《围城》里讲过的：

譬如咱们这次同船的许多人，没有一个认识的。
不知道他们的来头，为什么不先不后也乘这条船，以为这次和他们聚在一起是出于偶然。
假使咱们熟悉了他们的情形和目的，就知道他们乘这只船并非偶然，和咱们一样有非乘不可的理由。
这好像开无线电。你把针在面上转一圈，
听见东一个电台半句京戏，西一个电台半句报告，
忽然又是半句外国歌啦，半句昆曲啦，鸡零狗碎，凑在一起，莫名其妙。
可是每一个破碎的片段，在它本电台广播的节目里，有上文下文并非胡闹。
你只要认定一个电台听下去，就了解它的意义。我们彼此往来也如此。

在做神付神点的时候，
连续几个月我跟 @hulucc 都是公司最晚走的两个人，
后半夜我们就会一边写代码，
一边聊着游戏、A岛或者是人为何活着，
hulucc 给了我许多不亚于 rick&morty 给我的启发。

这几年我也少有跟各个伙伴促膝长谈的机会，
但不论是四号线的地铁、莫干山的萤火虫，
还是雨树湾的电脑旁，海南的夜空，
都是我这几年工作里难得的回忆。

刚毕业的时候看《代码大全》，
里面提到“假如你每年看一本技术书，你就已经超越了90%的同行了。”
当时的我嗤之以鼻：“你把工程师描述的太无知了。”
但我现在也时常惊醒，今年（2020）的我一本技术书都没看。

每段输出都是因为有一段输入，
所以尽可能地去拥抱每一次输入吧。

（未完待续）

[原则] 永远在路上

Sun, 24 May 2020 22:02:34 +0800

这天，坐在显示器前的我，
用键盘写下了我的这条原则：
永远在路上

我做事实际专注于事情本身的用时占比并不高，
倒是会花很多时间在自我对话、自我思考上。
不论是事前、事中、还是事后，
以局外人的角度去思考问题总会特别有趣。

而且为了渡过年月事务发展的长河，
我就会借由思考为绳，
把一根根名为原则的竹子，
绑成我的一艘小竹筏。

今天我想分享的一条原则，叫：

永远在路上

不拘泥于表达本身的话，
这句话还可以是“永不停歇”，
“生命在于折腾”，
“百尺竿头更进一步”。
更加具体地阐述永远在路上这句话，
就是：

假如一件事情一天就做完了，
那一周后再去回顾下结果；
假如一周里你跟新朋友建立了友谊，
那就让这份友谊再延续一年；
假如你在一年后站到了不一样的高度，
那就让这样的旅途持续一生。

永远在工作路上

工作中，我信奉的“永远在路上”，
就是每天把每件事都做的比昨天更好，
即使大家都以为这件事已经完结了。

我能看到很多人做事情，
只会把事情本身做好。
在完结后，
也许是“不在其位不谋其政”，
也许是觉得事情已经足够好了，
这个事情的结果就不会比结果更好了。
我做事情不会选择这么做。

在《为什么我喜欢工程师文化》中，
我提到了我司的 the Hitchhiker's Guide to ZaiHui Dev,
俗称“新手村任务”。

三年前入职的时候我推着补完了这篇文档，
我便在业余时间一直维护着直到现在，
算上各种重构的内容，已经贡献了一万多字了，
加在一起顶我好几篇文章了…

但也就是这样一篇文章，
让我能坦然地跟我们的面试候选人说：
“可能我们整套工程师培训体系不算完美，
但你做完这套新手村任务以后，
就能直观地感受到我们做事的风格，
并且喜欢上这个地方。”

就像那个流传很广的说法一样：
“入职一天离职，怪流程；
入职一周离职，怪HR；
入职半年离职，怪Leader；
入职三年离职，怪文化。”
即使像文化这样玄乎的概念，
也是在一天天的维护升级优化中做出来的。

永远在情感路上

情感里，我信奉的“永远在路上”，
就是以初心来面对一切情感交流，
不做二元论的决策。

人类就像是穿梭在三维世界的四维生物，
他会走过不同的世界。
很多曾经的好友，
会因为共同经历变少而慢慢疏远；
也有感情稳定的双方，
会因为“我们关系很好啦”的松懈而分离；
更多的时候，
我们会看到“没有人比我更了解他”的单方判定。

现在经常可以在社交平台上看到汹涌的观点，
但这些被汹涌着裹挟的情感，
也只不过是“有一说一，这件事不过如此”的瞬时理解。
在那些消费主义记录美好生活下，
《90后的你负债多少？》或许才是更真实的大众情感。

情感是复杂的，
但幸好，人也是复杂的。

永远在生活路上

生活上，我信奉的“永远在路上”，
就是用一切方法避免
“此人，死于20岁，葬于60岁。”

我很早就感慨过，
自己很怕成为那种
“工作三年=工作一年+重复两年”的人。
就像“科技三定律”戏谑的那样，
真实生活中许多人在一定年纪就死在了自己的舒适区里。

而我不一样，
就算我也死在了舒适区里，
~~我也要在墓里用这腐朽的声带喊出~~
我也要死的晚一些 :)

近期因为花在看书上的时间少了，
而且看的书里成功学占了不少…
所以写作的时候常常感受到自己笔力不足。
虽然以前也会感受到自己笔力不足，
但是最近的羞愧里还包含了：
“写了这么久文章还是笔力不足”的感受，
头就更大了。

但我每次回头看过去的自己写下的文章，
我都能从拙劣的遣词粗糙的造句里，
看到当时的我独特的想法，
往往这些想法还会给几年后的我带来不一样的启发。

自然而然，
我的想法、我的行动就会跟着时间一直传承发展下来，
这使我感受到了自己生命的活性。

结语

在《如何构建工程师团队》的结尾中，
我这么写道

就像唐代斯在最后赠给马克西米连的“等待与希望”一样。
我的朋友，作为工程师的我想送给你两个词，
它们饱含着“递归”、“复利”乃至“宇宙膨胀”的内在哲学：
思考，坚持。

永远在路上，
其实就是这样一个原则。

（完）

如何加速 Docker Build 构建过程

Wed, 22 Apr 2020 22:28:53 +0800

Dockerfile

docker 已经成为现代开发的基础技术，
而在 docker 开发流中，
Dockerfile 是最基础的文件。

一个包括了系统配置、依赖安装、业务代码的 Dockerfile 可能长这样子：

FROM python:3.8-buster
WORKDIR /app
COPY Pipfile Pipfile.lock ./
COPY code /app/code
RUN pip install pipenv
RUN pipenv sync
RUN echo "Asia/Shanghai" > /etc/timezone
RUN dpkg-reconfigure -f noninteractive tzdata
RUN apt-get update
RUN apt-get -y dist-upgrade
RUN apt-get -y install vim tmux git
RUN curl -sL https://sentry.io/get-cli/ | bash

然后很自然地，
开发者小周发现：
每次改完代码以后重新 docker build 都非常慢。

他需要加速构建过程。

改写文件

最简单的加速是改写 Dockerfile,
因为 Dockerfile 中的一些命令 (ADD/COPY/RUN) 会产生新的 layer,
而 Docker 会自动跳过已经构建好的 layer。
所以一般优化的原则基于以下几点：

变动越小的命令，越靠前，增加 cache 使用率。
合并目的相同的命令，减少 layer 层数。
使用国内源，或者内网服务加速构建。
少装些东西，不是代码依赖的就尽量别装了…
记得加上合适的注释，以便日后的维护。

改写以后的 Dockerfile 可能长这样：

FROM python:3.8-buster
WORKDIR /app
# 默认使用上海时区 + 阿里源
RUN echo "Asia/Shanghai" > /etc/timezone && dpkg-reconfigure -f noninteractive tzdata && \
echo "deb https://mirrors.aliyun.com/debian/ buster main non-free contrib" > /etc/apt/sources.list
# 预装必须的包，sentry-cli 是预先存入内网的
RUN apt-get update && apt-get -y dist-upgrade && apt-get -y install git && \
wget https://internal-nginx-service.domain.com/sentry.sh /usr/bin/sentry-cli && \
pip install pipenv
# 装依赖，顺便祝 pipenv 早日发布新版本
COPY Pipfile Pipfile.lock ./
RUN pipenv sync
# 代码频繁变更，放在文件底部，下面就别加更多命令了
COPY code /app/code

改过以后的版本，
开发者小周发现，
每次本地改完代码 build 调试都飞快，
他很满意。

但是用公司的分布式 gitlab runner 构建以后，
他发现：
有时镜像没用到 cache，又跑了一遍漫长的构建过程。

分布式构建

在 codebase 足够大的情况下，
CI/CD 一般都是分布式多台机器的，
默认的 docker build 只会从本地寻找 cache layer,
无法应对如此复杂的场面。

简单的办法是使用 docker build --cache-from 指定镜像，
我们会在 ci 脚本中这么写：

docker pull LKI/code:latest || true
docker build . -t LKI/code:latest --cache-from LKI/code:latest
docker push LKI/code:latest

但是这样手写的弊端是逻辑比较臃肿，
比如要完美适配多分支构建 (dev/master/hotfix/release) 的话，
往往就要自己实现一套判断究竟 cache from 哪个版本的逻辑。

更通用的办法是使用类似 GoogleContainerTools/kaniko 这样的工具来构建。
最适合 kaniko 的场景是 kaniko + kubernetes,
但这个我们留到最后一章再讲，
我们顺着我们的工作流往下看。

使用 kaniko + docker 的构建，
我们可以把上面的 pull/build/push 三连改写为以下这样：

# 这个命令包括了 cache/build/push
docker run \
 -v "$CODE"/LKI/code:/workspace \
 gcr.io/kaniko-project/executor:latest \
 --cache=true \
 --context dir:///workspace/ \
 --destination LKI/code:latest

and Kubernetes?

上面提到，kaniko 可以直接丢到 kubernetes 集群中构建：

apiVersion: v1
kind: Pod
metadata:
name: kaniko
spec:
containers:
- name: kaniko
image: gcr.io/kaniko-project/executor:latest
args: ["--dockerfile=Dockerfile",
# 没错，可以直接从 s3 里捞代码构建
"--context=s3:///bucket/code/",
"--destination=LKI/code:latest"]
volumeMounts:
- name: kaniko-secret
mountPath: /secret
restartPolicy: Never
volumes:
- name: kaniko-secret
secret:
secretName: kaniko-secret

随着研究的进一步深入，
很容易想到，
其实 docker 开发流跟 kubernetes 的开发流理应有更好的集成。

这就是 GoogleContainerTools/skaffold 在做的事情了。
skaffold 不仅支持前面讲到的 kaniko 构建，
还囊括了 port-forwarding/test/helm-deploy 等一系列常用工作流。

有兴趣的同学可以自行了解，
关于 skaffold 的故事我们以后有机会，
再慢慢讲 :)

若初见与吴建国

Tue, 21 Apr 2020 21:37:59 +0800

若初见总是很喜欢跟吴建国一起放学。

（一）
每次放学路上，
若初见总是非常跳跃地跟吴建国在讲在学校的见闻，
吴建国也总是默默听着。

若初见说今天语文考试，
老师出了一道他特别喜欢的附加题。
吴建国问这题是什么，
若初见说附加题是解释你名字的含义：
“我的名字若初见，
就人生若只如初见嘛，
多么简单但帅气的名字。”
“不会有点中二吗？”
“中二是在别人反应过来以后，
但第一次认识我的人肯定觉得我超帅。”

“不过这个也看人，你就做这题就不行。”
若初见看着认真看路走路的吴建国说道。

（二）
若初见的朋友很多，
但吴建国的朋友不多。
不过若初见也会跟吴建国说：
“你这样挺好的，做你自己。”

吴建国问：“你是怎么让大家都喜欢你的呢？”
“很简单，做自己就行了。
我能跟他们从魔戒的精灵语系聊到南方公园的政治正确，
也能从强人择原理讲到窃格瓦拉，
没人不喜欢我。”

吴建国感慨道：
“那是，你懂的挺多的，
我觉得我懂的就越来越少了。
可能是上学让我越上越狭隘了。”

“这怎么会呢？”
若初见一边说一边绕着吴建国转了个圈，
“你看嘛，俗话叫江山风月本无常主，
只要你有心，我们这放学路上都是风景。
比如你看，这棵树其实在对你笑，
但是实用主义的人类并不知道。”

“你再看，天边隐隐约约的月亮，
从他的视角看过来其实我们跟台湾的好友都在一个视界里，
视线的视。
这就叫人类的渺小跟天涯的共比邻。”

“比如还有一种说法叫‘回首之处皆是虚无’，
这句话是我瞎编的，但瞎编这个词是中文里固有的。”

吴建国听着若初见讲的一大堆，
若有所思但又若隐若现。

（三）
吴建国跟我们普通小孩一样，
觉得学校是个认真学习纪律严肃的地方。
但每次放学路上，
若初见总会跟他吐槽各种学校的不合理。

“我们数学老师定了一个特别捞的规则，
叫考试拿积分，期末换奖品。
首先不说我觉得物质奖励反而会削弱学习的精神回馈，
这制度明显有问题：
得一次全班第一得 20 积分，
但每进步一名就得 1 积分；
我们班上一共 48 个同学，
那我拿两次第一还不如一次倒数第一、一次正数第一刷爆进步奖？”

说干就干，
平时考满分的若初见，
下次考试的时候故意考了0分。
为了确保自己是有实力的，
若初见把所有的答案都右延了一位，
A变成了B，√变成了×，42变成了43。

听到这种操作后，
吴建国都呆了。
不过若初见自豪又失望地补充道：
“不过这张卷子老师还是给了我满分，
并且取消了积分奖励这个不够合理的制度。”

吴建国听出了这句话里的失望：
“怎么感觉你有种不够尽兴的感觉呢？”

若初见耸了耸肩，表示无所谓。

（四）
这天放学若初见很伤心，
他爱的人并不爱他。
吴建国没心没肺地安慰他道：
“没事，你像我这种长得丑的就没这种烦恼。”
“嗯，你不懂。”
一句话又把吴建国给噎住了。

走了几步，
若初见还是忍不住继续感慨：
“我感觉，
一开始喜欢我的朋友们，
后来情感连接总是会慢慢褪色，
最终大家会发现我其实不是个一直有趣的人。
吴建国，你说世界上这么多外冷内热的人，
有没有可能存在外热内冷的人呢？”

“你知道吗？我觉得这是你目前的知识构成导致的。”
吴建国停下了脚步，
想了一下措辞：
“以我对你的了解，你其实一直在追求新鲜而未腐烂的知识。
不论是你说的‘树也可以有生命’还是‘可以从月亮的角度来观察地球’，
他们都会在听到的一瞬间被吸收完所有价值。
就像你的名字‘若初见’一样，
一切的惊艳都留给了初见。”

看着情绪逐渐低落的若初见，
吴建国赶紧补充道：
“不过这样也没问题。
就像刚才说的，我长得丑。
但丑的时候爱我，才是真的爱我。
美的时候不必爱我，美的时候人人都爱我。”

（五）
若初见总是很喜欢跟吴建国一起放学。

（完）

旅行之二·do things matters

Sat, 08 Feb 2020 21:48:32 +0100

蜜月旅行第二站，
从德国的慕尼黑到科隆，
再到西班牙的巴塞罗那、格拉纳达。

收费厕所

上次讲到德国展示了一种整洁地很严谨的城市风貌，
这种感觉还体现在了一点上：收费厕所。

在德国，
不论是旅游景点的厕所，
还是商场的厕所，
很多都要收个 0.5€ 的入场费。
（残疾人厕所例外）

这让上遍天下厕所的我有点恍惚(x。
我记忆中的上一个收费公厕，
还是矗立在中学时期的人民广场公交车站旁，
欢迎着搭车上学的我的光临。

我以奇葩说式问句问 Mia:
“以后中国的所有公厕都要收五毛的入场费，
你支持吗？”
Mia：“当然支持啊，前提是收费后得像德国一样干净。”
我：“我也支持，前提是得支持微信/支付宝缴费。”

于是谈笑间我们又使用了一次“如果电话亭”。

如果电话亭

“如果电话亭”是哆啦A梦带回来的一个未来科技，
在它的帮助下，
世界能以你想象的方式运作。
xkcd 的 what-if 系列也有这个功效。

科隆大教堂旁边就是莱茵河，
莱茵河上面躺着一条霍亨索伦桥。
这个桥的特别之处并不是它名字很魔戒，
而是关于它有的都市传说：
把锁挂在桥上，钥匙丢进河里，爱情就会锁住一辈子。

经~~标记重捕法~~大致估算，
桥上挂了至少三十万把锁。

Mia 跟我又聊起了在桥上挂锁情侣们的各种可能。
就像钱钟书关于收音机的比喻说的一样，
万千人类有着万千悲欢。
也像鲁迅说的一样，
我可以觉得他们聒噪。

Mia 跟我感慨，
如果我们遇到的时间不是这么好，
那可能我们就会错过了。

这让我想起我爸偶尔也会感慨，
如果当时他英语能再考好一点，
他最终可能会缺少很多简单的幸福。

大雄还是像往常一样，
经历了失败后把“如果电话亭”还给了哆啦A梦。

人类的个体的此刻，
只不过是他漫长生命的一个切片，
这大概就是高维生物的悲哀。

自然

当参观人文景观的时候，
你总是需要各种各样的背景知识、作者分析、阅读理解、脑内作文。
但自然景观不一样，
就仿佛是大自然直接把大片蓝天、延绵山岭、无边海洋给甩到了你的脸上，
感知一下就从脑子掉进了脊椎血脉中。

在巴塞罗那最后一天的下午我们去了蒙锥克山，
没有云的天空就像是蓝屏的 windows，
看不见的空气弥漫着植物的清香，
在山顶上看到的海天线就像是《楚门的世界》里看到的一样无暇。

欧洲的小雨是跟着云走的，
而每朵云是跟着它的心情走的，
心情好就跑边上玩了，
心情不好就一边哭一边到处窜。

所以地球这边打伞的人类比例明显下降了，
下雨了就戴个帽子躲躲雨，
出太阳了就懒洋洋地晒下阳光，
非常惬意。

上海咋不是这样呢？
我不禁想。
可能是因为不是盟军，
没有天气控制器的原因吧。
我不禁这么回答自己。

高迪

虽说地球这边的天空令人沉醉，
但作为游客还是得有游客的自觉，
抱着包就在巴塞罗那踩遍了热门的人文景点：
米拉之家、巴约之家、圣家堂。

这些建筑都有一个共同点：
建筑师都叫高迪。
精确的来说，
建筑师都是同一个人，他叫高迪。

具体的彩虹屁就不吹了，
希望读者们有机会也可以去看看。
它最令我感到神奇的一点是：
高迪把“业务代码”写成了“传世名作”。

米拉之家其实就是有个有钱人叫米拉，
他出钱让高迪帮他建房子，
但高迪硬是把一个工程作品做成了一个艺术作品。
巴约之家也是如此。

想到这，
我瞻仰圣家堂彩绘玻璃的眼神，
明亮地更加复杂了。

do things matters

我以前跟朋友们论道时，
经常会被反问的问题是：
“像 Linus 的确是厉害啊，
不过我们这种写业务代码的，
也不可能做出他们那样的作品吧。”

这种时候，没有作文素材的我也只能更玄学地说：
“世界会因你而闪耀，
最终我们肯定都会搞个大新闻的。”
干巴巴的解释也只会让朋友苦笑着回答：
“你能这么想是因为你不一样……”

我的朋友，
米拉在发布他的建房任务时，
他也不会说：“我要建一个世界文化遗产。”
高迪拿到的不过是“给米拉建一个房子”的任务，
世界上也有千千万万的工程师拿到了建房子的任务。

但世界因为高迪而改变，
他用自己的才华跟心血把事情做出了不一样的杰出。

我脑子里面立即蹦出了一句 slogan: do things matters。
这不仅意味着努力去核心岗位做重要的事情，
还意味着每一件事都会因为是我做的，而 ‘matters’.

世界上只有一个高迪，
世界上也只有一个你，
do things matters

（完）

旅行之一·可能回不去了

Fri, 31 Jan 2020 06:38:22 +0100

蜜月旅行第一站，
从上海到多哈再到慕尼黑的城市中心。

时差

老实来说，
这是我第一次体会到物理时差，
以前都是生物精神时差控制着我。

慕尼黑在东一区，
我现在离 ED 在的伦敦更近了，
让我更能悟到半夜上线看到 ED 跟他夫人在刀塔的心情。

晚上十点多我就睡过去了，
第二天凌晨五点自然醒来后，
我跟同样早醒的 Mia 说：
“诶，看来时差是的确会影响人的生物钟诶。”
Mia：“哦，我平时这个点都是自然醒的。”

疫情

第一天在住处安定下来以后，
我们想着打电话问问卡塔尔航空的国内客服，
看回去的航班会不会被取消，
结果电话中提示：“不在服务时间中。”

微博上不少同学说，
因为疫情在国外有被差别对待，
我感觉其实还行。
大马路上的陌生人也并不会有什么交流，
外国人对中国人造成的语言伤害，
未必有其他省同胞对湖北同胞造成的语言伤害大。

连上了国外的网，
Mia 与我依然刷的是国内的疫情。
Mia 感慨：“感觉我们像是逃到了个没人管的地方。”
我义正言辞地回答：“慕尼黑不是法外之地！”

出租

我们叫了辆出租从机场到酒店，
土耳其的司机大叔操着浓重的口音跟我们讲：
“Don’t taxi. Take trains!”

土耳其大叔说他在德国呆了二三十年，
但就最近德国人都疯了。
我们问为什么，
他说超市里的口罩全被抢光了！

……

我们路边经过了很多标着 BMW 标记的建筑，
司机说：慕尼黑经济是这边的 number one,
一方面是因为举世闻名的啤酒节，
另一方面也是因为这里有很多的 Fabric.
我：“Wow, great!”
后来 Mia 提醒我，
这个 Fabric 是司机的德英混用口音的一部分。

生活

德语一直给我一种很硬核的感觉，
虽然我并不懂多少德语，
也就靠两句 Gutten Tag 跟 Danke 走天下。

我们住在慕尼黑中央火车站旁边，
城市的建筑分布是非常严谨的街区式，
横平竖直非常让强迫症感到愉悦。

在住处洗手的时候，
我摸到水龙头里特别细腻的水，
非常惊讶地跟 Mia 感慨道：
“这水看起来好干净啊，甚至有种能喝的错觉！”
Mia：“可以喝，但没必要。”

乡村

去天鹅堡的路上，
德国向我们展示了它的大乡村风貌。

广袤的田野上散落着许多尖顶红瓦白墙房，
簇拥在一起的样子就是《席德梅尔的文明》里城镇的样子。
大片的田野都没有种特别的庄稼，
都是平整的草地与没有人类的清新空气。
我跟 Mia 讨论说，
这要是在中国，
那多么浪费田地呀，
也不种些白菜胡萝卜葡萄西红柿什么的。

不过即使是没什么人的田间小镇，
德国人还是会把房子的白墙刷的非常干净。
这种感觉也在我们去了各式各样的洗手间以后冒了出来：
德国城市是真的会注意干净整洁。

这很好，值得学习。

食物

第一天放下东西以后，
我们去尝试了猪肘与本地啤酒。

猪肘的皮做的硬又脆，
整一大块肉吃起来腻得很沉醉，
于是盘里还会配上一堆腌白菜跟一块大土豆丸子。
本地的小麦啤酒闻起来很香，
除此之外也给不出什么对照组的评价了。

本地的食物店全部都在卖面包跟咖啡，
这里的面包有很多种：
有一大类是纯硬的干面包，
以至于店里会有专门的电锯切割机来切面包；
还有一大类是近似于三文治的面包，
里面的馅会囊括奶酪、生菜、西红柿、腌黄瓜、腌猪肉等一切能加的配菜。

来了这么几天，
面包是吃了很多，
米饭是一粒没沾，
有一种我已经不住在中国的错觉。

物价

作为一个外来客，
很多可能本地人习以为常的设定我都觉得很新鲜。
比如一点是这里的物价比例是不一样的。

Mia 与我去逛本地的超市，
我们在牛奶区流连忘返：
一支 1L 的牛奶只要 0.99€！
于是我三天内喝了两升牛奶放了一堆屁。（是真的）
在水果店，我们买了两斤多的苹果也就花了 1€ 左右。

与便宜的基础食品对应的，
在其它的一些方面显得就比中国贵很多。

比如我们坐公交，
单程一趟就要 5€ 左右。
理发店一次洗剪吹就是 20€ ……

更好玩的是，
我们买一瓶 1L 的~~农夫山泉~~纯净水，
总价是 0.44€，
其中水的价格是 0.19€，
但是瓶子的价格是 0.25€。

erlangen

在德国的第三天，
我们买了张单日票坐火车去 erlangen 找老韩玩。

德国的车站也不需要什么身份证明，
既没炸鸡验票口也没固定座位，
买了票自己上车找空位坐就行了。
我立马想起来小学时候看的检票员系列笑话，
果然是一方水土一方笑话。

老韩是 Mia 十年的好友。
写到这我也是一惊，
我们大学的同学，
现在换句说法居然能说是十年的好友了，
时间真的不经花。

我在 erlangen 看到了开放式的大学，
Mia 跟我说德国的大学都是这样的。
整个小镇也不大，
一条主街横穿了整个镇，
主街两旁分布着图书馆、面包店、啤酒厂、教室、流动图书室、大型商场。
整条街上行走的都是充满朝气的年轻面孔，
大学就像是被拆成了许多条隐形的河流，
与 erlangen 这个镇融合在了一起。

我们问老韩周末一般做什么，
老韩笑着说：
“他们说现在国内朋友的感受，
就是我们留学生的感受，
非常无聊。”

不过在了解到德国有不少程序员的需求，
没有摆在台面上的年龄歧视，
网速很好，
外界诱惑不大一般不出门以后，
我泛起了 30 岁开始重拾德语的小心思。

未完待续

这几天卡塔尔说部分去往中国的航班已取消，
虽然我们的航班还没受影响，
不过总顶着一种“回不去了呢”的快乐心情在游玩。

在德国我们还会去科隆大教堂，
到巴塞罗那了还计划去巴塞罗那主教堂等一系列景点。

希望到时候能忍住信仰之跃的冲动，
按 E 同步就够了。

（完）

软件工程实践之 Git 开发流

Tue, 14 Jan 2020 21:39:31 +0800

软件工程实践系列文章，
会着重讲述实际的工程项目中是如何协作开发软件的。
本文主要介绍如何使用 Git 来支撑整个开发流。

outline

本文包括以下内容：

operation: 团队保持一致的操作
- commit: 提交原子性的代码
- history: 保持线性干净的历史
- release: 遵循科学的发布规范
tool chain: 搭建自洽的工具链
- gitlab/github: 使用现代的开发平台
- ci/cd: 让系统把控代码质量
- sentry/k8s: 用版本连接整个系统
conclusion

operation: 团队保持一致的操作

Git 提供了一套自由而又强大的 api,
我们可以通过它以各种姿势来完成代码协作。
但俗话说得好，
选择越多人越懵。~~并没有这句俗话~~
所以在团队协作时，
保持一致的操作是很重要的。

commit: 提交原子性的代码

Git 的最小单元就是一个 commit。
我们团队遵循的最佳规范是保持每个 commit 的原子性：
一个 commit 只做一件事情。

比如一个关于缺陷修复的 commit 可以非常简单，
它只有两行：
一行修复了代码逻辑，
一行加了单元测试。

另一个关于重构的 commit 可能会修改 200+ 个文件，
但也因为只做了一件事情，
所以不会给 code review 带来很大负担。

原子性的 commit 不仅能很好地支持 revert/cherry-pick/bisect 等一系列 Git 的原生命令，
而且在保持线性干净的历史这一点上，
也是至关重要的。

history: 保持线性干净的历史

随着时间的推移，
Git 的每一个 commit 会成长为一个枝叶繁茂的历史树。
基于 fast forward 的合并能让 Git 的历史树保持干净与线性。

这是我们项目 git log 翻到四个月以前的一张截图，
可以看到历史依旧是线性干净的。

线性的历史意味着在每个人提交代码前需要 rebase。
一个例外是在发布分支(master)上提交 hotfix 后，
合并回开发分支(dev)需要视情况关闭 fast forward (–no-ff)。
而且要求大家 rebase 则对团队成员的 Git 水平以及合并习惯提出了一定要求。

干净的历史则需要大家都严格遵循 commit 的原子性，
以及要按照标准撰写 commit message。
关于 commit message 的撰写，
阮老师有一篇《commit message 编写指南》讲的够好。
我们也可以在 git hook 中开启对 commit message 的校验，
以确保格式的整洁统一。

通过fast forward merge + 统一的 commit message，
我们就能维护一个不断成长、但又干净线性的历史树，
能最大程度地给各种 git 的版本操作提供便利。

release: 遵循科学的发布规范

我们使用 git tag 来作为版本发布的标志。

因为我们的项目是一个 web 服务端项目，
我们同一时刻基本上只需要维护最新的版本，
所以我们使用了日期型的版本号数字(v2019.9.9)。
在大部分开源工具里，
都会使用语义化的版本号(semver: v2.0.0)。

基于原子的 commit、线性的历史，
在每次版本发布时，
我们都会自动化地生成 tag/changelog。

一个遵循了良好规范的 tag 能最大程度地利用工具链的集成功能，
给开发、测试、上线、监控提供完备的功能。

tool chain: 搭建自洽的工具链

在注重团队协作、开发流程、发布质量的软件工程中，
会有一系列开发工具围绕 Git 的代码历史树，
提供了自洽的工具链。

gitlab/github: 使用现代的开发平台

我们使用 GitLab 来管理代码项目，
其中重度使用的是 Merge Request 来作为 code review 的载体。
~~不过我们跟着 GitHub 的设定，管它叫 PR (Pull Request)~~

为了维持 PR 的原子性，
大部分情况我们遵循单个 commit 对应单个 PR，
这样既方便 review 也方便分支管理。
不过这样的开发流会产生非常多的 PR，
需要团队开发者都保持在一个更积极的开发状态下。

现代的开发平台还会集成更多工作流上的功能，
我们还重度使用的是把 GitLab Runner 作为我们 ci/cd 的工具载体。

ci/cd: 让系统把控代码质量

在提完 PR 以后，
系统会自动化地启用一系列的 Python/Django 检查。

通过 git tag 发布版本后，
系统会自动化地跑构建、灰度等一系列部署任务。

除了 GitLab Runner,
其它像 Jenkins/Travis CI/GitHub Actions 也可以类似的 ci/cd 功能。

集成 ci/cd 能让整个开发流变得更加柔顺，
让每一个改动的影响都可以即时地通过数据展示出来。
ci/cd 加上 code review，
能最大程度地让代码库保持活性，
长远地能避免“往屎山上堆屎”的发生。

前面提到我们的 PR/release 频率都会比较高，
所以 ci/cd 也需要在更短的时间内跑完，
以避免龟速检测导致的各种心态爆炸、skip ci。
目前我们项目平均能在 5min 内跑完包括 96% 覆盖率的单元测试的多项检查，
也能在 5min 内跑完从构建、灰度到全量的整个发布流程。

整个 ci/cd 的流程其实也跟写接口这样的业务类似，
是需要不断迭代、不断优化、不断适应更好的开发流的。

sentry/k8s: 用版本连接整个系统

在开发的流程走完以后，
软件工程还关心发布的流程、质量把控的流程。

我们绑定了 docker image tag 与 git tag，
最终发布部署在 k8s 上的每一个版本也跟 git tag 的版本强关联。
这样的设定之下，
比如像 kubectl rollout 的一系列操作就会跟 Git 历史树关联上。

我们也使用了 sentry 来检测管理代码的线上问题。

所有的外部系统都使用着统一的 tag version 来关联问题，
这样我们就给 debug, 历史溯源，分锅都提供了统一的工程语言。

conclusion

基于 Git 的开发流不是一个一成不变的框架，
它会因为项目特质、团队成员习惯、工具链的不一样而有着不同的表现形式。

我们团队在软件工程的实践中，
保持并维护着这么一套开发标准：

保持 commit 的原子性，一个 commit 只做一件事情。
遵循编写 commit message 的标准，并且会在 code review 时关注。
统一团队成员的操作习惯，使用 rebase + fast forward merge。
自动化地生成 git tag 以及 changelog，并基于此做代码发布。
搭建快速全面的 ci/cd 流程，自动化地做掉所有代码检查。
使开发流与社区最佳实践一致，了解并利用好各类工具的集成功能。

这套开发流也给我们提出了这些挑战：

要对 Git 有一定了解，包括历史树操作等进阶知识。
除了编码时，在协作时也要保持积极的态度，以及协作上的高标准。
最重要的，对最佳实践的追求，以及不懂就学的态度。

这样的 Git 开发流，最终带来了这些效果：

线性的历史让 debug、追溯变更、了解项目发展过程都变得非常友好。
项目一方面能保持快速活跃的开发效率，另一方面能保证长期维护的质量。
最佳实践的讨论以及迭代，让团队内部一直维持着很好的工程师文化。

软件工程的实践中，
好的 Git 开发流是不可或缺的一部分。
以后我们再以不同的视角来分享更多软件工程的实践。

（完）

软件工程实践之平滑发版

Mon, 09 Dec 2019 23:39:28 +0800

软件工程实践系列文章，
会着重讲述实际的工程项目中是如何协作开发软件的。
本文主要介绍了如何无中断地发布版本。

outline

本文包括以下内容：

why
how: 其实平滑发版大体可以分为两部分。
- service: 服务层做好切换管理就行。
- database: 数据库层就是标准操作。
example: 举个实际的栗子。
conclusion

why: 为什么要平滑发版？

ldsink 说过以前他在百姓网的时候，
他们一直保持的实践就是“随时都准备好发版”，
这样不仅能保持功能上线的敏捷度，
还准备好了应对各种变化。

当时我们的一体化服务每次发版都要停服几秒钟，
几秒钟对应的就是用户触发的一堆 5XX 网络错误。
更不用提发版更频繁的开发测试环境，
前端爸爸们经常惊呼：
“诶？服务器 502 了！诶，我刷新一下又好了……”

后来在我认真研学了以后发现，
平滑发版其实是一个非常普世的话题，
任何涉及网络流量分发、请求逻辑处理的服务都会有这部分功能。

平滑发版的英文是 gracefully upgrade/reload/restart,
常用的工具都会对平滑发版的流程有完善的支持，
用工具名直接搜索就行了，比如 nginx gracefully upgrade 或者 k8s gracefully upgrade。

为什么要平滑发版呢？
其实核心目的就一个：
防止发版带来的服务中断。

how: 如何做到平滑发版？

在实际工程中，
大部分的 web 服务本质都是从外部接受请求，
从数据库查询、处理数据返回。
本片中就以这个逻辑，
按 service/database 的平滑发版来逐个介绍。

service: 业务层的平滑发版

我们团队后端语言框架用的是 python/django，
详细情况在前文《软件工程实践之 django/python》中有介绍。
我们目前的网络链路是
(云负载均衡) -> (k8s-ingress-controller) -> k8s-pod(nginx+uwsgi)

云负载均衡跟 k8s-ingress-controller (目前用的是 kong) 的变动都不会太频繁，
就不过多赘述。
每次发版变动的都是业务服务，在前面的链路中指的就是 k8s-pod(nginx/uwsgi)。

不论是 k8s/docker/systemctl/supervisord/pm2,
他们通用的逻辑是系统信号 (Signals)。

Signal	x86
SIGHUP	1
SIGINT	2
SIGQUIT	3
SIGKILL	9
SIGTERM	15

part of unix signal numbers

以 k8s 为例，当旧的 pod 被终止时，k8s 执行的具体操作如下：

发送 SIGTERM 信号，然后等待最多 terminationGracePeriodSeconds(default=30) 秒
假如等待过程中，服务停了，那就做其它终止操作
假如等待过程中，服务没停，那么就发送一个 SIGKILL 信号

一般来说，标准的框架实现都会支持 SIGTERM 与 SIGKILL 的语义，
但具体的额外自定义逻辑就需要自己去实现把控了。

业务层确保请求不中断，
需要正确处理信号。

database: 数据库层的平滑发版

数据库层会涉及到发版变动，
主要可以分为数据的变动、结构的变动。
核心的处理方法是双写。

先讲一下关于数据变动的双写。

比如我们以前有个字段A，
存储的是布尔值 true/false,
后来含义变丰富了要改成枚举值 0/1/2/3。
那么整个流程得是：

增加默认为空的枚举值字段B。
第一次发版引入双写，代码逻辑中涉及字段A的写入逻辑，以同样的逻辑增加对字段B的写入。
清洗数据，把所有字段A的值以同样逻辑洗到字段B里。
第二次发版摘除双写，代码逻辑中涉及字段A的读取逻辑，全部以字段B替代。
确定正常以后，下掉字段A。

2~4 的这一步是以双写的方式处理兼容，
持续时长会因为具体的情况而相差很大：
可能 10 分钟就双写完了，
也有可能因为要给清洗大量数据留足时间而持续数天。

再看一下关于结构变动的双写，
核心逻辑跟上面的 1/2/3/4/5 套路五步是一样的。

增加字段：这个很简单，增加完字段以后再发版即可。
删除字段：这个也很简单，发版摘除相关逻辑以后再删除即可。
修改字段：假如是不兼容的改动，应当以增加新字段+双写+删除旧字段的逻辑来处理。

数据库层确保请求不中断，
需要以双写保证兼容。

example: 举个实际的栗子

我们的 django 服务是以 nginx+uwsgi 的方式起来的，
nginx/uwsgi 本身对 SIGTERM/SIGKILL 语义有着良好的支持。
但同一个 pod 的情况下经常会出现 race condition，
nginx 有时会比 uwsgi 终止的更早，
最终导致请求中断的问题。

网上的老哥们也遇到过类似的问题，
解决方法也简单地有点滑稽：
加点 sleep

container:
name: nginx
lifecycle:
preStop:
exec:
command: ["sh", "-c", "sleep 10 && kill -s HUP 1"]

除了一般的服务层跟数据库层，
我们还用到 celery 做了异步 worker。
celery 对平滑发版的支持不算特别好，
所以像社区里提的一样，
自己在 task 层面处理信号。

conclusion

总的来说，工程上实现平滑发版（无中断发版）核心思想是：

服务层：处理好系统信号。
数据库：用双写保持兼容性。
其它：确保链路上的每一点都是无中断的，才能达成真正的平滑。

通过这么一系列操作，
我们就可以轻松地做到用户（包括拼命人肉 DDOS 测试环境的前端爸爸们）感知不到我们在发版，
最终达成那句“随时都准备好发版”的状态。

当然了，
随时发版到此时也只是技术层面的可行，
并不是意味着实际工作中真的会每时每刻都发版 :)

毕竟软件工程不仅牵涉软件技术，还有人的工程呀。

（完）

搭建一个不需要自己开服务器的纯静态博客

Tue, 19 Nov 2019 01:00:07 +0800

又名：我是如何从 jekyll 切到 hugo 的。

本文会包括以下内容：

背景
博客搭建
使用感受
挖坑

背景

前几个月一个老哥给我发邮件：
“commentit 已经凉了啊，记得换掉！”
我才意识到这个静态评论系统已经到了项目终结期。
连 GitHub Repo 都 archive 了。
然后我又意识到：
已经有一阵没有翻修我的主页了。

这可不行，
生命在于折腾。

于是趁着最近换了新的编码环境，
我重新整了一下我的博客。
俗话说，一图胜千言，
先放张翻修过的博客图：

博客搭建

这一章节讲的是枯燥的步骤，
下一章节才讲充满偏见的个人感受 XD

不想自己维护服务器的话，
托管在 GitHub Pages 上是个很好的选择。
四年前我用 jekyll 搭博客的时候也写过一篇：
《这篇博客是怎么建成的》。
大体上，搭建一个功能完备的静态博客分为这几个步骤：

找一个静态内容框架
装一个静态评论系统
配配件：主题、域名等

搞框架

hugo 的安装非常容易，
直接用命令行或者去官网下载就行了：

brew install hugo

然后按照官方的教程，
一键创建目录 + 默认主题启动就行了：

hugo new site quickstart
cd quickstart
git init
git submodule add https://github.com/budparr/gohugo-theme-ananke.git themes/ananke
echo 'theme = "ananke"' >> config.toml
hugo server -D

其它高阶玩法读文档就是了。
至此，第一步，找框架算是做完了。

搞评论

utterances 也是一个利用 GitHub Issues 来做评论的工具，
它利用 Primer 达成的 GitHub 还原度非常高。

安装也非常简单，
找个模板页把它的配置写上就行了：

<script src="https://utteranc.es/client.js"
repo="[ENTER REPO HERE]"
issue-term="pathname"
theme="github-light"
crossorigin="anonymous"
async>
</script>

对应的效果如下：

其它配件

我用的主题是 joway/hugo-theme-yinyang，
整体的简约风格让我很喜欢。

字体的话，由于是个人博客，我就没用 FiraCode 这种严谨的字体了，
英文字体我用的是 ipython/xkcd-font,
中文字体我还在寻找一个可爱的手写体。

域名的话，默认会开启 lki.github.io 这样的域名，
需要用自定义的域名可参考官方文档：github-custom-domain
设置里记得开一下 HTTPS:

要统计访问人数的话，可以用静态计数器不蒜子做到：

使用感受

我之前的博客系统也是用的 GitHub Pages，
工具链是用的 jekyll + commentit。
整体有这么几个感受：

用 GitHub Pages 相比于自建博客而言：
- 爽：不需要维护
  平常在公司做的后端已经够多了，并不想花时间研究自己博客的 502 (x
- 爽：便宜
  呃，拥抱开源，拥抱开源。
- 烦：访问速度不够快
  不过这个是 GitHub 的原因，烦也没用。
- 烦：受限制
  比如评论功能，要是自建博客的话实现起来很轻松。
用 hugo 相比于 jekyll 而言：
- 爽：有新鲜感
  有一说一，确实。
- 爽：hugo 是 go 写的
  之前为了 jekyll, 还得在电脑上冗余一套 ruby 的环境，而 go 的环境天然就有。
- 爽：默认值选的很恰当，不需要过分定制
  不论是 configuration 还是 archetypes, hugo 给我的感受更好，而且 hardLineBreak 这个选项真的好用。
- 烦：GitHub 只支持自动构建 jekyll
  加个 git pre-push hook 其实就可以解决掉这点，不是特别大的问题。
用 utterances 相比 commentit 而言：
- 爽：默认样式更好
  之前 commentit 的样式是我手写的，作为 css 苦手无数次倒在了 inline-block 上…
- 爽：用 issue 同步评论的方式才是正确的
  commentit 的哲学是通过 git push 来挂载评论，但是经过实践以后，其实还是用 GitHub Issues 来更王道。

另外值得一提的是，
在考虑从 jekyll 迁出时，
我也认真考虑过 hexo。
不过最终是因为 hugo 看起来更迷人，
同时也为了坚持当时放弃了 hexo,
选了 jekyll 的不必要的倔强(x

附 star 增长趋势对比

还有一个开心的小的点，
就是这个主题对微信公众号的排版支持的比起以前好多啦 :)

挖坑

目前的博客改造算是告一段落了，
接下来肯定还是回归到认真工作、认真记录生活的节奏中。

而对于博客本身，
其实还是有不少可以做的坑：

用 Primer 统一正文评论样式。
找个好玩的中文手写字体。（其实这条跟上面那条会冲突）
像 TravisCI 一样提供切换字体的选项。（除了 cooooool 以外并没什么用）
把友链功能给加上，认真给大家介绍一下我的好友们的实力
找个办法，把以前 commentit 的评论优雅地展示出来

要列的话，
能想到要填的坑是一个又一个。
毕竟就像鲁迅常说的那句话一样：
“个人博客是值得认真搞一搞的，
毕竟生命在于折腾嘛。”

（完）

[轶事] 为什么 requests 不是 python 标准库？

Wed, 30 Oct 2019 22:32:20 +0000

前几年一次跟耗子哥聊天，
他说：“你终有一天会从 stackoverflow 上找 bugfix,
进化到从 github issue 里找 bugfix.”
一语成谶。

头部注释

我非常喜欢@灵剑说的这么一段话：

软件维护有两种截然不同的思路：
一种是所有的依赖都追踪最新版，
一旦出最新版立即开始试用；
另一种是所有的依赖都选择一个不会变的固定版本，
能不升级就不升级。

看见软件的新陈代谢，给写代码的我带来了无穷的热爱与动力，
同时也给我带来了很多 github issues…

代码是人写的，bug 也是人写的，bugfix 也还是人写的，
github issue 的文字里也充满了各种各样有血有肉的充满既视感的评论。
issue 的文字虽然隔着时间空间上的距离，
但就像 xkcd 979 - wisdom of the ancients 表达的那样，
有些情绪就是亘古不变的。

在工作中 debug 的时候，
对于具体的 issue,
同事们都留下过很多精彩的讨论。

鉴于这样，
我决定开辟一个“轶事”的专栏，
专门来讲一讲那些好玩的 issue.

为什么 requests 不是 python 标准库？

原文地址:
https://github.com/psf/requests/issues/2424

Kenneth Reitz 是一个业界知名的程序员，
很多人了解他可能是因为他从两百多斤的胖子变成一个超帅的玩摄影的程序员，
其实专业过硬的他是写出过 python-requests, httpbin 等好用的工具库的。

requests 这个库重要到什么程度呢？
根据目前可以公开的情报看到，
GitHub 上的引用数高达 389k，
是 python 语言下引用数最高的库。

于是很自然的，我就产生了这样的疑问：
“为什么 requests 不是 python 标准库呢？”
作为项目的主开发，
Kenneth 在 2015 年初，
还在 python 3.5 的年代就向社区抛了一个问题：
“假如 requests 要加入 python 3.5 标准库，你们有什么想法吗？”

的确，一个库进标准库是有利有弊，要经过社区讨论的。
所以其实我的问题应该要改一个字，
从“为什么 requests 不是 python 标准库？”
改成“为什么 requests 不进 python 标准库？”

整串讨论看下来，基本是有这么几个意见：

优势是
- 降低使用成本：让很多小白也能直接上手用标准库的了。
- 扩大使用范围：很多只依赖于标准库的项目，也能用上 requests 了。
劣势是
- 开发流程问题：标准库的严格流程，跟社区开发的流程完全不一样，最终可能导致开发者流失。
- 依赖问题：现有的库依赖了不少证书之类的文件，在进标准库的过程中需要大重构。
- 进化速度问题：进了标准库以后，接口跟实现就会固化，很难随着外部世界改变而快速变化到最好的状态。
- 其它历史问题：以前的 urllib 库为了兼容其实已经很臃肿了，也是需要重构的。

总的来说，
社区的反对意见跟忧虑会更大一些，
更原汁原味的评论大家可以看一下原串。

整个讨论中还有几个我感兴趣的点：

@Lukasa 在串首来了个起手式：“先问一下几个大佬，他们的看法是怎么样的。”
然后 at 了 @shazow @kevinburke @dstufft @alex @sigmavirus24 这五个人。
里面我只知道 alex 是写 cryptography 的，其它人其实都可以认识一下。
串讨论到一半的时候 @dcramer 留了些关于“我只用标准库依赖”的评论，
然后留下一句 not sure what you're all bitching about 就跑了…
我就不敢这么放肆…
Kenneth 在 requests 库的文档中曾写过这么一句话：
Essentially, the standard library is where a library goes to die.
结果就在讨论过程中多次被揪出来“打脸”质疑了。
（其实还好，设计哲学是可以设计的嘛）
今年四月也有个老哥 @4evermaat 抛了这个问题，
他在看完四年前的讨论以后，留下了这么一句感慨：
I didn't realize there was so much politics in getting a module included in the stdlib.

在讨论结束过后四年的现在，
requests 库依然以一个独立的社区项目生机勃勃地新陈代谢着，
python 3.5 以后也增加了标准库 urllib.request 支持一部分核心功能。

代码既是人设计的，
也是给人用的。
它们背后的故事，
也是程序内在逻辑的一部分。
这部分逻辑曾经在一个个讨论串里存活着，
最终也让代码更加鲜活地呼吸着、代谢着、生存了下去。

（完）

没错，DNS TTL 字段就是骗你的

Tue, 29 Oct 2019 21:49:42 +0000

By design,
the Internet core is stupid,
and the edge is smart.

引子

前几天在网上冲浪的时候，
看到了一篇讲 DNS 的宝藏文章：
DNS TTL Violations in the Wild.

之所以对我来说是宝藏文章，
因为在读了第一段以后，
我就发现了一个我习以为常的认知其实在实际是错误✖的：
业界都会遵守 DNS 的 TTL 超时逻辑。

然而实际上是：
业界都知道 DNS 的 TTL 超时逻辑，但不一定这么实现。

事件

前几周我们出了个 Bug,
影响了整个开发、测试环境。

我们有很大一块的业务是跟微信做各类 py 交易，
微信要求说我们给个回调域名，
每 10 分钟会推送一个凭证，
我们要用微信最新的凭证去调他们的接口。

最早我们给微信配的回调域名背后是个 AWS ELB,
这是一个亚马逊云上面的旧版负载均衡；
后来我们打算换成新版负载均衡 AWS ALB。

这个操作就很简单嘛，
到 DNS 服务商里看了一下，
微信回调的域名解析 TTL 是 600 秒，
又是开发测试环境；
于是我们直接把解析改到了新版负载均衡上，
~~（出于省钱的想法）~~顺手还把旧的负载均衡给删了。

哦豁。
微信一天都没有给我们推授权凭证。
于是我们开发测试环境的微信功能挂了一天。

有的时候开发测试环境出问题，
会跟生产环境同样煎熬。
因为你会发现你身边的同事，
每隔 10 分钟就会问你：
“弟啊，微信好了没有？”

疑问

在改 DNS 的 86400 秒以后，
微信的凭证又成功地持续给我们推送了。

根据现象判定是 DNS 的问题以后，
一边在心里鄙视微信，
一边也产生了疑问：
“不科学啊，DNS 这么基础的服务，怎么会出 bug 呢？”

这就回到了本文开头讲的：
业界都知道 DNS 的 TTL 超时逻辑，但不一定这么实现。

每一条 DNS 记录都由两部分数据组成：
什么域名应该指向什么目的地？
我的有效时间是多久？
而这两部分数据会以互联网特有的树状结构层叠而上，盘织交错。
在终端进行 DNS 寻址时，
链路上的任何一个 DNS 服务器都可以实现一套标准或是非标的逻辑。

对于 TTL 这个值，
只有三种实现的逻辑：

缓存时间等于 DNS TTL 时间。
缓存时间小于 DNS TTL 时间。
缓存时间大于 DNS TTL 时间。

世界

要我来写域名服务器的逻辑的话，
不出意外我会严格按照定义来实现。
当然，根据性能、时间、空间的限制，
最终实现出来会有几秒的误差，
不过这不关键。

关键的是，有不少人觉得 DNS 目前的设计是有缺陷的。
而作为整个互联网的底层构架，
不论是要提升还是替换 DNS 目前的逻辑，
都是一个非常巨大的工程。
当然，这也更吸引工程师为此献身了。

于是，当今现实世界里的域名解析，
就不是完全按照“缓存时间等于 DNS TTL 时间”来实现的。

当缓存时间小于 DNS TTL 时间时
- 主要争议点在与这个会给上游服务器带来更大的解析压力
- 高频解析也意味着更多的带宽、网费支出
- 但这种情况不会伤害终端用户
当缓存时间大于 DNS TTL 时间时
- 主要的问题在于，这会让用户访问到错误的服务器
- 这不仅会带来逻辑错误，还会有潜在的安全隐患
- 在本文最开始出现的问题，其实就是微信的 DNS 链路上出现了缓存过旧的问题
- 好处可能就是在解析费上不用交那么多钱了(x

总结

总的来说，DNS TTL 是一个在互联网基础设施中广泛使用的约定。
但是现实世界中也会有很多非标的实现。
由于 DNS 的特殊性，每一个非标的域名商都会影响一大片他们能触达的用户。
所以在我们操作 DNS 时，要优雅的解决问题就也得把他们给考虑进来。

工程上的问题就是这样，
既有理论的优雅，
又有凡人的愚蠢，
也有分布式的智慧。

By design,
the Internet core is stupid,
and the edge is smart.

（完）

Pythonista 的 Go 之旅

Thu, 13 Jun 2019 01:10:49 +0000

背景

我们团队后端主要技术栈是 Python,
具体的软工实践在前文 django/python 里有详细的介绍。
由于平时做公司业务主要写的是 Python,
自己做的项目也是 Python 工具，
所以其实一直想尝试体验一下 Go。

正好上周有空，
于是体验了一下 Go 的基础设定，
用 Go 写了一个小服务（微信消息推送）。

这篇文章讲的就是一个 Pythonista 的 Go 萌新之路。
有理解谬误、操作不当的地方，
请各位多指教了。

语法

上手一个语言，
总是习惯性打开 learn x in y minutes 先过一遍语法。

Go 的特别之处是它的关键字非常少，
这让 Go 的语法很容易被记下来。
总的来说我觉得这几个语法很好玩。

循环

// 直接 for 就可以写死循环
for {
 fmt.Println("while true...")
}

// range 这个关键词用起来很舒服
data := map[string]string{
 "key": "value",
}
for key, value := range data {
 fmt.Println("while true...")
}

枚举

// iota 居然被做成了关键字
// 这里后面的俩 iota 是可以省略的
const {
 Unknown = iota // 0
 Male = iota // 1
 Female = iota // 2
}

// 也可以满足隔 10 定义枚举的喜好
// `iota << 2` 这样位运算定义 1/2/4/8 也是可以的
const {
 Unknown = iota * 10 // 0
 Male = iota * 10 // 10
 Female = iota * 10 // 20
}

多表达式判断

// if 语句会取最后的表达式值，所以这么判断是很常见的
if f, err := file.Open(path); err != nil {
 return Response(400, err.Error())
}

// 这样判断布尔值也是常见的操作
if data, ok := json.Unmarshal(body); !ok {
 return Response(400, "invalid json body")
}

goroutine

// go 的天生并发也是非常优雅的地方
func sendTemplate() {
 // 这里是耗时很久的网络请求
}

func handleRequest(ctx Context) {
 validate()
 // sendTemplate()
 // ↑ 假如为了速度，我们不能同步发送模板，那么我们用 `go` 这个关键字就可以一键异步 ↓
 go sendTemplate()
}

项目

第一章的语法过了以后，
很快就到了第二章：
《如何用 go 起一个项目》

要写代码，首先就得把文档给翻出来看看。
于是第一站便是官网 golang.org

Go 的官网其实非常友好，
从最基础的教你怎么配环境、写初始的项目，
到 Effective Go 这种全面长文都浅显到点。

上手装好语言环境以后，
首先跟 GOPATH 这个环境变量玩了一下。
不过后来发现 Go 1.12 以后自带 go mod,
只要简单了解一下这个概念就行了。
那我们先放一下，
直接上手感受 Go 的工具链吧。

工具链

Python 装好以后主要自带的是个 REPL 跟 pip 这个包管理器。
Go 装好以后，会自带包括 fmt/test/vet/mod 等一系列的工具。

go fmt
- 这个是上手 Go 第一印象最大的工具
- 它是一个不支持配置的代码格式化工具，非常严格
- ~~prefer tab over space~~
go test
- 自带 coverage, 很好用
go vet
- 似乎是自带的 linter

玩 go test 的时候发现它是针对 package 来做测试的，
而 Go 里面，
package 的概念也是非常突出。
比如调用包方法的时候是要加包名的，
所以最佳实践里也有“命名不重叠”的规则。
（举个栗子，比如方法应该叫 xml.Parser 而不是 xml.XMLParser）

写业务

由于我们写的是一个对内网以 RESTful 风格提供接口，
然后调用微信发送消息通知用户的这么一个小服务，
按照 Python 的惯性就想找个 django + wechatpy 的组合在一周内来完成业务。
简单调研了一圈，选了 gin + gorm 两个大的工具。

Go 的第三方库给我的感觉是非常直白。
因为引入第三方库的方式是 go get -u github.com/gin-gonic/gin，
直接拉的就是 GitHub master 分支的最新代码，
所以感觉整个第三方的社区是基于分布式共识的，
只有大家都遵守社区规范，
才不会有挖矿代码的出现…（虽然中心化也会有挖矿代码）

文档的话，调研阶段读的其实都是 GitHub README，
GitHub 是经常逛的网站，
各个库的 README 风格也都是 markdown 风格，
读起来也很轻松。
真正要看 godoc 的地方不多。
因为拉的是源代码，
所以基本上都是直接读源代码，
体验跟 Python 非常像。

具体业务代码就先略过了，
没有什么特别的。

部署

开始准备部署的时候又有不少好玩的话题。
比如 Go 的多环境配置。

Python (Django) 的多环境我一直用的是环境变量 + 多配置文件，
Go 的话去看了一下社区，
基本也是类似的原理。
可以用环境变量，
也可以用多配置文件（比如 yaml），
还有一个就是用命令参数（flag 库）。
Go 社区里其实比较推崇用 flag，
因为这样可以把配置跟代码（执行文件）融为一体，
更加利于维护。
不过我最终还是选择了环境变量 + 多配置文件…

项目的编译、部署我们用的是 GitLab CI/Docker。
也是 ci-build/test/compile/docker-build/deploy 五个套路阶段。
Go 里比较特别的是会大量引用 GitHub 以及 Google 官方提供的代码，
在国内拉的速度比较慢，
所以为了加速构建，
我们也自己搭了相应的加速通道去提升速度。
目前来说，从代码进主干分支，
到自动发版大概耗时不超过 3min。

性能

自己写的小服务上去了，
那首先就要 wrk 一下测一下 QPS 啦。

Python(Django) 默认的其实是同步模式，
基础支持的 QPS 很低，
我们用 gevent + uwsgi 协程模式特意调优过，
一个获取服务器当前时间的简单接口，
在 1CPU+4G Memory 的小破机器上，
Python(gevent) 的 QPS 大概能到 1000，
而未经调优的 Go(gin) QPS 能到 10000。
真有你的啊，Go。

社区

在玩 Go 的一周中，
其实我真正的有效编码时间不是很长，
大部分时间都徜徉在 Go 的各种社区最佳实践文档里。

在我眼中，
除去 Go 语言本身的很多闪光点，
Go 的整个语言社区运营也是值得其他语言学习的。
比如上面讲到的官方推的工具链，
这能有效提升所有项目的下限。
Python 去年也刚出了一个格式化工具 black，
自己宣称是 the uncompromising code formatter。
（Python: 别催，在学了在学了）

感受

讲了这么多看似中立，
实际都是感受的发言，
我来集中总结一下我的感受。

我很菜

写 Go 的时候我是能直白地感受到自己很菜的。
一块是很多地方我能感知到有语法简化的可能性，
但我的语言表达能力还没达到优化的水瓶。
比如 Go 2 Draft 里的 check 关键字，
我隐约感觉好像基于 panic + recover 也能实现类似的机制，
但真要写又写不出。
而 Python 我就感觉能完全写成 Lisp。

另一块是库的使用，或者叫“语言生态”。
不论是平时用到的标准库，
还是后端业务要用的各类三方库，
或是工程化用到的单元测试、质量把控的库，
我都只能在用到的时候做现场调研。

总之因为基础知识缺乏，
加上熟练度不够，
写 Go 的过程就总有一种“我好菜啊，这个都不懂”的奇妙感觉。

我喜欢 Go

菜并没阻止我表达喜欢 :)

Go 身上透露出了非常老派的 KISS 原则，
它甚至很多时候给我的感觉是比 Python 还要简约。
比如最佳实践会跟你说：
“不要过早拆文件，
一个目录十个文件能解决的问题不需要分层。”

相比 Python 而言，
Go 的执行速度透露着一种不讲道理的快。
Python 深入了解并发模型，
调优 CPU 跟语言参数以后的结果，
还是跟 Go 差了一个量级…
（不过开发速度上 Python 还是巨快…）

而且，
Go 还有可爱的 Gopher 呀~

Go 的实践

目前我司后端的主技术栈是 Java 跟 Python，
我主要写的是 Python。

以我短暂的体验而言，
Go 在关键的高性能服务上会有很好的表现，
但在新业务的原型、Web 层的多业务上，
Python 魔法般的开发速度还是无人能比的（叉腰）

目前后端的各种流行框架基本都是语言无关的，
我们可以根据不同业务的适用场景来选择合适的技术栈。

企业在选择技术栈中，
其实也会考虑其它更现实的因素，
比如开发人员的招聘难度，
代码库、技术栈的统一，
大型团队的解耦管理。
这些其实也都是非常有深度的、值得探讨的话题。

写了一周 Go,
我更坚信自己的理念了：
“工程师是解决问题的人，
技术是解决问题的工具。
软件工程没做好说工具难用，
是何异于：
刺人而杀之曰，非我也，兵也？”

后续

一周的体验卡有点太短了，
非常意犹未尽。

后续有时间的话，
关于 Go 的这些话题我会继续研究：

产线环境上的服务部署姿势。
Go 的服务可视化（监控、日志、追踪）
用黑魔法让语言表达力更高的基础库
跨语言服务间的交互实践

欢迎交流，
也对文章里的不当之处作出指正批评。

（完）

密度不高地生活了一下子

Tue, 11 Jun 2019 22:50:03 +0000

好久没记录思考了。
虽然陶菲格一直在催我在思想逝去前记下来，
但我总有种感觉：
最近的人生密度不是很大。

今晚照常以社畜的身份下班回家，
米娅已经刷完日常准备睡觉了。
听着她断断续续哼着耳机里不知道什么歌的旋律，
好久没去唱歌的想法突然从我脑子里游了过去。

“唉，最近又觉得人生好虚无了。”

晚上进楼道电梯的时候，
有两只母蚊子跟了上来。
她们绕着裸露在短袖外面的手臂转了好几圈，
靠着敏捷高，
躲开了我好几下拍击。
于是我双手交叉，
假装在电梯里思考人生，
趁蚊子被我的冷静愣住的时候，
嗖一下冲出了停稳的电梯。

现代人的确太容易陷入集体性情绪了，
而个人的悲叹又显得太无力。

米娅上周收获了一个她的宝藏节目《乐队的夏天》，
几十只乐队的现场后劲加在一起，
抵得上《波西米亚狂想曲》的后劲。
她昨天晚上突然问我：
“你作为 A 站老用户，
有没有那种自己喜欢了很久的小众爱好，
后来突然火了感觉很挫败的感觉？”

在“我不是我没有别瞎说”的第一否认力还没生效的时候，
我脑子里闪过了一百个单词。
“有，还不少。”
我还是这么回答了。

在米娅下一个问题还没问出口之前，
我也提前给了她答案：
“是的，后面我就不喜欢了。”

最近工作感觉比较无力的一点是，
我真切地感受到了“技术不是瓶颈”在工作中的存在，
有不少同事也因为这点而另谋高就了。
虽然说新陈代谢是组织保持活力的必要成分，
但“生命很大世界更大”这句话也重复的有点疲惫。

谈谈《谈 996》

Sun, 14 Apr 2019 15:16:24 +0000

很多人会喜欢 Lisp 里的宏 (Macro)。
语言里的宏提供了一种元编程 (Meta-Progamming) 的能力。
假如你用过魔兽世界里的宏，
你也可以想象这里的“元游戏”是什么意思：
它注重的不是游戏本身，
而是对游戏求导所得出的“游戏的本质”。

今天这篇《谈谈<谈 996>》其实是我想写的一篇方法论的文章，
或者我更喜欢称之为: Meta 文章。

历史的进程

最近因为 github/996icu 项目引出了一系列的事件，
在我看来基本上是像人血馒头一样是可以吃的津津有味的。

一次大型的社会性事件中，
最好玩的是看人类社会的不同角色对事件本身发表的看法。
而且基本上“屁股决定脑袋”或者说“你会成为你喜欢的人”这种道理都是不变的。

每当这时候我就会想起筱敏写的那句话：

1789年7月14日巴黎人民攻克巴士底狱的当夜，
当路易十六听闻消息时惊慌地问：
“这是一场叛乱吗？”

他的廷利昂古尔公爵当即回答道：

“不，陛下，这是一场革命。”

社会是由人类组成的，
所以这个整体有的时候会表现出奇特的单人所不具有的特性，
进而进行组织性的进化与修复。
最终回过头看，
不禁就会发出江学长那样的感慨：
个人的奋斗是很重要，
但也要兼顾历史的进程啊。

言论管理

我其实蛮喜欢看一些八卦文章的。
（比如推荐一个博主叫“萝严肃”，
他写的长文都会查不少背景知识）
石原里美在文章里经常被表扬“表情管理”做得很好。
同样地，“言论管理”也是资本家会被重点关注的一处特质。

带着这点去看各个资本家的行动，
就很有意思了。

有一部分资本家的言论管理就是少说话，
外界对他们的评价就是“比较技术”。
而很大一部分资本家的发言就很精妙，
他们会为了心中更美好的世界而发言。

但可惜的是，
人类的悲喜并不相通。

涉及公益、教育这种大家都认可的话题还好，
但工作这个话题本身就涉及社会性分工，
不同的人会因为不同的事情有不同的感受。
假如资本家在“996工作制度”这个话题上直白的表达“我非常享受工作本身”及其类似的观点，
很自然地会收到无区别的批判，
因为这个时候他的原罪是他的身份。

当一个人的符号属性重于社会属性时，
他发表的所有言论都应当有明确的导向性目的。
这就是“言论管理”。

自我认知

以前上学考试结束以后，
总有人会哀嚎“哎呀考试考砸了完了完了。”
结果最后他成绩非常好。
虽然也有个说法叫“本质是因为怕被认为无能”，
但不论如何，
假如你的行为轻信了他人的言论，
就很容易被误导进坑里。
最终导致“其它人都是嘴上喊着成绩差，结果你是真的成绩差。”

就跟上面一节说的一样，
现在的信息流（包括你正在看到的这篇文章）都充斥着言论管理。
一个信息是否有价值影响个人的行动，
是需要被识别、筛选并取其精华的。

接下来的这段时间我们会看到更多的关于 996 的言论，
有些会刺耳，有些会很解气。
但是哪些里面蕴含了“建设性意见”，
就需要我们睁大眼睛去辨别了。

当他们在谈论 996 的时候，
我在思考的是这个谈论本身。

（完）

软件工程实践之 django/python

Wed, 10 Apr 2019 22:09:55 +0000

软件工程实践系列文章，
会着重讲述实际的工程项目中是如何协作开发软件的。
本文主要介绍了 django/python 系列的工具链。

outline

本文包括以下内容：

outline
django: 一个搭建后端服务的工具箱。
- framework: django vs flask/tornado/spring/laravel
- restful: django/restframework/swagger
- worker: django/uwsgi/gevent/celery/channels
- database: django/mysql/sqlite/migrations
python: 一门依赖开发者的语言。
- developing: gitlab/pipenv/docker
- quality: unittest/pytest/flake8/pylint/yapf
- deploy: fabric/aws/nginx
conclusion

django

django 是一个大名鼎鼎的后端开发框架，
它自己的口号是 the web framework for perfectionists with deadlines.

在我用 django 开发的这几年来，
我觉得它是一个逻辑上自洽，
并且为了逻辑自洽甚至舍弃了一部分功能的框架。

framework

search google for django vs

讲框架避免不了的是同行竞争，
比如到网上搜一下 django vs ... 就有一大堆搜索结果。
其实框架之间的比较是很难的，
每种框架都有自己适合的业务场景。

xkcd-927: standards

django 最大的特点就是 Model 是一等公民。
在 django 中的所有的操作都会跟 Model 相关，
比如它提供了自带的强大 ORM,
也有一系列挂载在 Model 上的校验等。

个人感觉在项目的业务需求达到了某种程度的多样化以后，
基础框架用什么并不重要，
适合开发团队才是最重要的。

鉴于本文的标题是 django,
所以我们只讲 django。

restful

我参与的项目基本都是前后端分离的项目，
后端提供的接口都是用 djangorestframework 写的。
虽然像 HATEOAS 这样的高级属性还没用到，
但接口是遵循 restful 风格的，
比如像用 http method+status 表达语义，
对资源的定义等。

接口文档我们选用了 drf-yasg 来生成符合 swagger 规范的文档。
曾经我们也试过 django-rest-swagger 这个库，不过……

another help-wanted project…

使用现成框架的好处是语言表达力极强，
最终我们实现一个“解密微信提供的手机号”接口的伪业务代码大概如下：

class WeChatVS(BaseVS):

 @with_response(empty=True)
 @with_request(DecryptionSiri)
 @action(methods=['post'], detail=True, url_path='decryption/phone')
 def decrypt_wechat_phone(self, request, uid):
 """ 解密并修改用户的手机号
 - https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/getPhoneNumber.html
 """
 self.check_account_request(request, uid)
 openid, encrypted_data, initial_vector = self.request_data
 phone = WeChatManager(openid).decrypt_safely(encrypted_data, initial_vector)
 # TODO(ldsink): 找产品问一下外国手机号怎么处理
 hutils.check_error(not hutils.is_chinese_phone(phone), 'o(╥﹏╥)o 目前只支持国内的手机号')
 self.account.modify(phone=phone)
 return self.empty_response()

这样的十行代码包含了文档、外链、错误检查、写库，
让写业务代码本身也有种施法的快感。

worker

最开始服务器上我们跑的是 django+uwsgi 的普通模式，
用 wrk 去压一个小接口，
测试环境 4G 内存的机器 QPS 只有 40 左右。
后来加上了 gevent, monkey patch 一下，改到了协程模式
同样的接口同样的机器 QPS 上升到了大概 600。
调优一下效果会更好。
（需要更高性能的业务可能就根本不用 python 了 Orz）

celery 充当了我们的定时任务+异步任务框架，
我们也拆分了读写密集型/计算密集型的两类队列以处理不同的事情。
对于业务中的即时通知部分，
我们用了 channels 库来实现 web socket 的功能。

对于这些大型的框架，其实我们选择余地并不大。
比如虽然 django 开发者有说在 3.0 会考虑大幅度重写异步调用，
channels 项目会逐渐弃坑……
但毕竟 perfectionists with deadlines.
不能说人家功能不完美，我们就不干活了嘛…

database

我们用到的数据库也是 mysql/mongo/redis 这御三家，
所以就是每个选取对应的连接库就是了。

值得一提的是在单元测试里，
我们用 sqlite(in-memory) 替代了 mysql 数据库。
sqlite 里缺失了 mysql 的函数的问题，
也可以用 connection.create_function 的方法来规避掉。

在上线时，还有一个很好玩的东西是 database migration，
这个基本上跟“给行驶中的火车换轮子”一样刺激。
详细的细节以后会专门开篇文章讲一下（挖坑预警），
从结果上来说我们做到的是利用 Django Migration 做到数据库结构变更全兼容。

python

上面一小节中，我们基本上是走马观花地过完了 django 相关的三方库。
到了真正用 python 开发的时候，
我们遇到的更多的是框架之外的奇遇。

每门语言都有自己的味道。
我很喜欢 python 的一点是：
这门语言有着非常强的表达张力。
就像上面举的那段典型业务代码一样，
在实际的开发中，
python 是能完美表达开发者心中所想的。

但假如开发者自己都没想清楚自己要写啥，
这就有点不妙了。

所以我们有一系列的开发工具来保持清醒。

强制清醒.jpg

quality

贺师俊在《如何引导程序员新人按正确的流程开发？》下面一段我很欣赏的回答

除了开发流程上的类似要求，
我们对代码本身也执行了类似的严格要求：

单元测试覆盖率必须得在 96% 以上 (unittest/pytest/coverage)
代码的逗号、换行、引号的使用都必须符合规范 (flake8)
代码强制经过 linter 检验，禁止多种黑魔法 (pylint)
- 代码的各个模块之间必须符合特定的拓扑顺序 (pylint-topology)
代码风格（如字典的复制、长列表、换行与空行）强制统一 (yapf)

其中单元测试覆盖率必须得在 96% 以上值得被单独拎出来表扬一下。

业务代码的 96% 的覆盖率是什么概念呢？
这意味着代码里只有那种真正的边缘情况是没被测到的。
（比如为了兼容微信 SYSTEM ERROR -1000 写的代码）

为了达到了这么高的覆盖率，
我们也专门强化过单元测试的表达力，
比如一段测试创建用户接口的伪代码可能如下：

def test_create_account(self):
 """ 测试创建用户 """
 with self.assert_model_increase(Account, delta=1):
 response = self.client.post(self.account_url(), {'username': 'hulucc'})
 self.ok(response, username='hulucc', tags__length=0)
 with self.assert_model_increase(Account, delta=0):
 response = self.client.post(self.account_url(), {'username': 'hulucc'})
 self.bad_request(response, message=AccountErrors.DUPLICATE.value)

所有这些限制都在 CI 中检查了，不通过的话是不让 merge into master 的

developing

我们的合作方式是用 gitlab 作为代码托管平台。
为了团队的开发效率，
我们还自己写了个小机器人来处理各种如分支合并、有效性检查、贴标签之类的杂活。

gitlab ci 不仅被用来做开发阶段的质量保证，
最终我们的构建上线也走的是 gitlab ci (以前我们用的是 jenkins)

对于 python 的依赖管理，
我们用的是 pipenv,
pip list 一下大概有了 181 个库。
(关于 pipenv 的介绍可以参见《Python 依赖管理的未来 - ldsink》)

也因为我们线上用的是 docker,
所以不想装依赖的也可以直接用 docker 的环境开发。

deploy

部署这一块我们暂时还没上 k8s,
目前走的是 gitlab ci 中调用 fabric + aws(boto3) 直接操作裸 docker 的方式。
aws 的负载均衡器提供了基础的流量切换服务，
我们也是借用了现成的服务达到灰度发布、无缝发布的效果。

用 GitLab CI 部署的步骤图

conclusion

至此，本文介绍了一遍我们在 Python 业务后端的实践。

对于高可用、容器化、数据库等屠龙技，
业界其实有非常多的探讨，
大家也很容易找到现成的文章。

但具体到业务后端的工程化实践，
能借鉴的大型项目并不多。
我读过的也只有两年前的 reddit 代码跟 sentry 这个 django 项目符合要求了。

总的来说，我们用 django 在开发中遵循的约定跟共识有这些：

做正确的事情。
- 比如我们在讨论过后，一致觉得“线性的 Commit 历史是最干净的”，从当天开始我们的 Commit 历史就是干净的线性历史了。
自动化一切能自动化的工作。
- 用 swagger 自动化生成文档，用 gitlab ci 自动化质量保证。
尽可能使用最新的特性，让代码时刻保持崭新。
- 我们每隔一阵就会把所有依赖升到最新的稳定版。
- 不过因为这个我们也踩了不少坑。
- 不少时候三方库会引入全新的用法，动辄改动 100+ 的文件数。
- 这个时候就到了 Vim Macro 展现魔法的时候了。

假如你也在用 Django 作为后端框架的话，
不防尝试一下上面提到的各类工具，
绝对物超所值噢 :)

《流浪地球》电影观感

Wed, 06 Feb 2019 13:45:34 +0000

假如你想跟家人在春节去看场电影的话，
非常推荐去看看《流浪地球》。
（本文可能只有轻微剧透。）

电影

电影本身我认为是一个非常成功的类型片，
加上了国产滤镜跟科幻滤镜以后，
口碑在春节档电影里排第一也是可以想象的。

电影剧情的底子其实跟《钢铁侠》《超人归来》之类的超级英雄电影本质上是一样的：
主角出生 - 锻炼自己 - 遇到低谷 - 组成团队 - 创造奇迹 - 拯救世界。
这样的类型片近十年已经有不少了，
要想在他们中间脱颖而出，
需要能把故事讲好。

大刘（刘慈欣）就在这里发挥了非常重要的作用了。（我脑补的）

虽然电影故事是在原作小说一段子情节之上，
原创发挥出的独立故事。
但电影开场的字母上写了“全程监制：刘慈欣”几个字，
整个剧本也透出了一股浓浓的“刘氏直男科幻”的味道。

无论是最开始的“中国味道赛博朋克”的都市背景，
还是中间提到的“饱和救援”方法论，
甚至是贯穿电影的转折，
都用厚重的真实感冲淡了一部分超级英雄类型片本身的魔幻感。

进而这又引出了这个电影非常“共产主义”的一部分：
电影里的超级英雄不是个体，
而是人类这个集体。

之前看过一个说法，
说外国人看三国看到的是那个年代里英雄闪烁，
中国人看三国看到的是刘皇叔山穷水尽也要带上人民。
《流浪地球》也是一样，
虽然电影的镜头跟着主角一行人，
但是我们可以清晰地感知到：
是人类本身，在创造人类自身的历史。

除了原作者监制、共产主义精神这两点，
《流浪地球》电影里还有一点能让我露出“老母亲式”微笑的：
故事讲得圆。

整个电影埋了不少伏笔，
虽然有些可能让观众能猜出后面剧情的进程，
但是电影并没有给人一种“穿山甲最后怎么了？”的失落感，
基本埋的伏笔都用上了，
而且还疑似致敬了大刘另一本小说的剧情，
提到了一个彩蛋。

总的来说，电影本身的原作者监制、共产主义精神、故事讲得圆，
这三点让它成为了一部不错的类型片。
缺点的话其实要讲也有不少，
但在我的滤镜加持下就不提了。
额外提一句，假如是受“战狼PTSD”的影响有点怕吴京的话，
这部片里吴京武戏不多，
可以安心观影。

感受

先打个岔讲个好玩的
我是跟家人一起去看的电影，
去的是一家“4D电影院”。
我们都知道3D是指长宽高，
那多出来的第4D在哪呢？

电影里冰天雪地吹大风的时候，
电影院的扶手会朝你吹风；
电影里主角开车颠簸的时候，
电影院的椅子会疯狂颠你；
电影里东西砸下来的时候，
电影院的椅背也会猛击你背……
感觉像是去了一场欢乐谷…

北京市第三区交通委提醒您：
道路千万条，安全第一条。
行车不规范，亲人两行泪。

回到正题。

在我眼里这电影还有一点好，
就是它宣扬大爱的方式非常地中国化。

比如西方人拍的超级英雄电影，
宣扬的大爱其实是“爱能解决一切”，
“任何人通过努力都能做成任何看起来不可能的事”。
郭帆拍的是个啥子捏：
“中国人的爱就是回家过年。”
很难想象外国人会拍出“回家过年吧”的桥段来…
（当时电影院里也给我看的一愣一愣的）

最后电影结束以后（没有菜单），
字幕放了两首歌，
一首是刘欢的《带着地球去流浪》，
一首是逃跑计划的《夜空中最亮的星》。

看着结尾电影字幕里飘过的中英文制作组人员，
我有点出神。

之前看惊奇/漫威的电影，
Mia 跟我都会等到字幕结束。
然后一起指着“哇上面还有 HR 的名字”，
“IT 的名字也能上诶”。

那个时候我就在想：
外国能批量制造这么多的类型片，
是因为他们背后有强大的电影产业链在支持；
什么时候我们中国也有先行者拍点片，
然后带动一下特效、道具、剧本、投资的相关发展，
即使拍的稍微烂点，
我也愿意当个精神股东支持一下啊。
~~毕竟我真的很想看以北上广深为背景的超级英雄电影~~

希望“中国科幻电影元年”的说法能在今年敲定下来。
再许个愿吧，
希望大刘的《乡村教师》《球状闪电》也能被拍成电影，
等到相关产业链成熟了，
《三体》三部曲就可以拍它个七八部，
最终组成吴京大刘电影宇宙！

观影之外的还有几个很好玩的事情。

一个是去微博、豆瓣、知乎上看看《流浪地球》的口碑/票房发展。
毕竟从票房排片上来说，
小破球早期的目标观众还是泛科幻受众，
但口碑跟中国味是有望给电影带来不少自来水的。
品一品大众舆论也是很好玩的。

二是电影目测能带动大刘的相关小说销量。
虽然人类在他笔下经常被揉来揉去，
但是他特有的科学与人文结合的方式，
经常会给人一种“科学宗教化”的观感。
大家有兴趣的话也可以去读读他在《三体》之外的一些小说。
（比如《球状闪电》）

三是过节了，家人在一起要注意安全。

只有中国人拍的电影，
里面才会加入这样的台词：

北京市第三区交通委提醒您：
道路千万条，安全第一条。
行车不规范，亲人两行泪。

（完）

如何构建工程师团队

Mon, 28 Jan 2019 23:46:45 +0000

“工程师团队”这个话题我一直非常好奇，
我经常会问我的朋友们：
“你们公司这个是怎么样的？”
这篇文章讲的就是我自己对于这个话题的思考。

引子

上一篇《积极面思考》中提到了，
最近写的东西都更偏向于“道”一些。
本文虽然标题是叫“如何构建工程师团队”，
但其实讲的东西基本都是主观的想法，
或者不考虑标题长度的话，
更恰当的标题说不定是：
《我们仍未知道那天苏子岳脑海中幻想的是一个什么样的工程师团队》。

主要涉及的观点可能包括如下：

自己
- 像游戏主程序员一样工作
- 信赖，往往会创造出美好的境界
- 永远抱着初心者的空杯心态
团队
- 四世三公的三公指的是公平、公正与公开
- 用工具践行自动化
- 我爸爸是刘备：放权
文化
- 《程序员的二八定律》
- 《积极面思考》
- 在种田与爆兵中寻找平衡
其它的~~标题党~~话题
- 真的是写 PPT 的不如讲 PPT 的，讲 PPT 的不如听 PPT 的吗？
- 早上九点上班，晚上九点下班，一周上六天班，好吗？
- 《为什么我不招你当我的员工》
- 《搞 IT 的培训三个月就月入上万？》

本来这里想用单个词语来概括标题的（就像我以前的说明文那样），
但是想想，危言耸听胡言乱语好像也更加 Drama 一些。
那我们就篡改一下张梅的《写给未来的你》来引出正文吧：

要学会欣赏真，
要在重重面具下看到真。

世上的圆滑标准很多，
但出类拔萃却极少。
而往往出类拔萃又隐藏在卑琐狂荡之下。

自己

不论是构建团队，
还是追求事业，
人总是要先做自己，
以前的人管这叫“修身”，
外国也有部电影《修身客的救赎》就是讲这个的。

定位

像游戏主程序员一样工作

假如你在一个十人左右的技术团队当领导者，
你希望自己是一个什么样的定位呢？
我会希望我是一个游戏主程序员一样。
我从大学就有这个想法了。
（这句话的目标是澄清我没想蹭螃蟹科技的热点）

游戏的主程序员要做什么呢？
呃，其实我不知道。
不过有知乎上的顾煜在《What makes a good lead programmer》里说得好：

主程序员最常见的相关素质包括：
专业能力过硬、沟通效果良好、管理效率高、擅长目标分解。

主程序员也是从小程序员一路 level up 上来的，
他得解决让各利益相关方达成共识，
让大家在同心追求目标的路上噪音尽可能小。
只要有需要的话，主程序员还可以是所有人的兜底方案，
团队的锅第一个会落在他的头上，
难调的 Bug 最终也会落在他的头上。
能力越大，责任越大，讲的也是这个道理。

这样做的话，
业务上能不受阻碍地去推进，
技术上没有后顾之忧。
唯一算得上缺点的，
大概是成为主程序员不仅需要付出努力，
也得时刻警醒自己多加思考吧。

黄色的树林前有两条路，
很遗憾不能我全都要。
我选择了行人稀少的那一条，
它改变了我的一生。

方式

信赖，往往会创造出美好的境界

我其实一直很关注亚文化圈子。
（这个话题也是我一直想写篇文章聊一聊的）
假如说人跟组织是社会的细胞跟器官，
那么亚文化就像是社会的脉搏一样：
时刻变化，又无比精确地反映着社会的心跳频率。

如今的亚文化中，
“霸权”大部分情况处在负面的语境中，
而“丧”大部分的语境都承担着正向的情绪宣泄。
随着语言跟文化的解构，
越来越多的人会在跟他人相处中保持安全距离，
不轻易信任别人，也不竭力付出自己。

听着很有种“囚徒困境”的感觉对吧。
在“多次重复的囚徒困境”变种实验中，
最佳策略非常简单：
“一开始默认信任，之后一报还一报。”

就像超级英雄电影里演绎的一样，
一个团队假如大家单打独斗就很容易被逐个击破。
能获得最终胜利的方法，
都是大家相互信任，然后用 “Watch My Back” 式的宣言来达成目标。

从自己信赖别人开始，
往往就能创造出美好的团队信任感。

心态

永远抱着初心者的空杯心态

最开始钦定“主程序员”的原因，
往往是这货写代码又快又狠，
兄弟们都服他，
于是组织上一研究决定，
他就多了一个“带领大家一起冲”的任务了。

工程师团队的 Tech Leader 有不少都是那种“兄弟们跟我冲”的类型，
从一线出身的人很容易会有“我行我上”的冲动。
（事实上我也常有……）
但其实这并不科学。

假如所有的难题都是由主程序员来解决，
那么主程序员的实力就是团队的天花板。
假如是写的死规则，
那么围棋机器人的棋力最高也只能到编码的程序员这，
只有实战跟反馈能锻炼出会“机器学习”的阿法狗。

团队也是一样，
永远抱着初心者的空杯心态，
就仿佛自己就是最菜的。
毕竟假如自己这样都是最菜的，那么团队得有多强啊！

团队

去年难得追完了一整部番，
叫《中间管理录·利根川》，
体裁是很稀少的职场搞笑番。
这番横七竖八地透出了几个歪歪扭扭的字：
逢山开路，遇水造桥。（雾

氛围

四世三公的三公指的是公平、公正与公开

先打个岔解释一下，防止有人把上面这句我编的句子当真了。
四世三公讲的是袁绍身出名门、身份高贵，
他往上四辈祖先都是三公：大司马、大司徒、大司空（总之就是很厉害）

构建团队，在做好自己之外，
确定团队的氛围是非常重要的事情。
往远了说，团队的氛围会决定做事情的效率和效果，
会影响新人的融入、跟其它团队的对接；
往近了说，你要在这样的团队中担当主程的角色。
所以团队的氛围必须是你认为的正确。

公平、公正跟公开是我认为的正确。

公平，是指机会均等。
每个人都会有同样的机会、同样的空间去完成他的目标。
公正，是指权责平衡。
每个人因为实力不同，所以承担的任务、期待的产出也是不一样的。
公开，是指信息透明。
每个人都能获取到及时、准确的消息，不会因为内部的消息传达而影响了共识，进而影响到事情的推进。

其实工程师在这点上要求很低，
在分锅的时候讲清楚是什么、为什么，
怎么做就交给我们去决策，
最终工程师会选择合适的技术与分工方案去完成的。

听起来，
这个道理也同样适用于
“女朋友该如何使唤男朋友干活”呢。

流程

用工具践行自动化

人这个芦苇不仅会思想，
还会用工具。
工程师就更加了，
就像《工程师文化》中讲的一样：
工程师文化的其中一条就是用工具解决问题。

团队的工具暂且不提，
我所见过的优秀的工程师都有一个统一的特征：
擅长使用工具，甚至自己发明工具。

“程序员都是懒人，
但有些懒是能一劳永逸的。
他会写一段能自动泡咖啡的代码脚本，
然后每天都不用动手按下那该死的按钮。”

工程师的团队也一样需要工具来自动化各种流程。
从最基础的自动化的代码检查，
到自动化的持续集成、自动化的监控，
甚至是自动化的分工、自动化的沟通。
这里的每一项自动化都可以节约对应的人力，
或者从财务的角度：“提高人效。”

在我理想中的工程师团队里，
还有这么一拨工程师，
他们的任务就是给其它工程师做好用的工具。
可能在一线业务上会少两三个程序员，
但是整个团队的总生产力能大大提升。

权责

我爸爸是刘备：放权

这句话是“三国杀”游戏里“刘禅”的台词，
传达出了一种生在普通家庭的平凡感。

就像前面四世三公里聊到的，
公正意味着权责平衡，
这点也是工程师认知中非常重要的一环。
无论是有赞的年会宣言还是罗辑思维的公开信，
我认为都是权责问题上的无奈之举：
因为没能成为一个权责平衡的团队，
所以才要宣扬这个道理。

四世三公里的公正（权责）值得单独拎出来说，
因为在我的认知中，公正比公平难以执行，
但有的时候更正确。
举个栗子。

比如一个团队每个季度都要评一次绩效，
然后组织上规定，
每个团队的绩效都得排名，
总有一个人要吃 0 分。

（看似）公平的办法是什么呢？轮流来。
大家和和气气，轮流吃 0 分，
这次我吃蛋，下次到你家。
公正的办法是什么呢？按表现来。
在最能贴近事实的统计学数据下，
最差的吃 0 分。
假如一直是最差的呢？
那就一直吃 0 分。
当然，假如整个团队做的业务都崩了，那都吃 0 分，或者解散。

在公正的条件下，放权给每一个人是一个能把事情做好的办法。
我自己做的技术选型，之后重构也是我来。
我搭的基础设施，不好用我修。
我写的流程，在过年期间稳定撑过了高并发，甚至不用触发 on call，我牛逼。
自由触发自主，自主就会自豪。

一次我跟在拼多多的好友聊天，
他说他最喜欢创业感觉的一点是：
“跟产品经理过了需求，
我说三天能做完。
然后啪，一天做好测试上线了，
我感觉我可太牛逼了。”

文化

假如你们有注意的话，
很多组织或者团队不仅有文化，
还有文化的具象符号。
团队的文化就是团队的灵魂，
团队的灵魂是由团队的领导者所决定的。

精英

20%的程序员写出了80%的代码。

—— 《程序员的二八定律》

虽然程序员们喜欢把自己比喻成“码农”、“码工”，
职称也是叫“工程师”，
大学里学的也是叫“软件工程”。

但其实编码跟所有脑力劳动有着一样的特性：
人跟人的产出差别是指数级的。

诗人李白写的诗，传唱度比一万个末流诗人加起来还要高；
哲学家马克思的思想，影响了整个历史的进程；
自然语言学家刘半农创造的她字，催生了跨越千里的情书；
给顶级程序员一根针，他们就能在刻满一张 4GB 的光盘（梗）。

不提横向对比，
即使是一个人的产出也会有云泥之别。
一个程序员一天工作 8 小时，
可能他最专注的那 2 小时就做完了一整天的功能，
其他时间他只不过是往里面写新的 bug，
然后再努力找出来修复而已。

所以一个追求最终生产力的文化，
一定会把提升精英工程师的产出，
提高工程师的有效工作占比放在一个重要的位置。

比如让谷歌“臭名昭著”的 20% rule，
官方说法是每个工程师只分配 80% 时间在工作上，
剩下的 20% 的时间去做自己感兴趣的副业。
但其实这反而激发了工程师们的热情，
让一些人付出了 120% 的时间在业务上。
最终可能大部分 20% 的项目都没产生效应，
但是少部分 20% 的项目以及这些项目带来的文化热情传染是有着非常大的价值的。

上进

从正面去思考问题。

聊完精英这个话题，
很容易想到金字塔模型，
进而会有一个问题：
“那假如少部分工程师做了大部分产出，
剩下的大部分工程师怎么办呢？裁员吗？”

这个问题问的很有趣。

我的想法是一个团队在建立的时候，
是会经过一套标准恒定的人才筛选机制的。
这个背景下，从个人角度看来，
我作为团队里产出占比很低的人，
我也很绝望啊…
比如我们公司就有个前端，
他不仅做业务做的又快又猛，
技术问题上他也想法多，
一下就能薅一个 demo 出来。
你猜只能仰望他的我，会怎么想？

没错，我会希望自己也努力成为这样优秀的人。

好的文化不仅能催化顶级人才的产出，
还能让有潜力肯努力的优秀人才进化成顶级人才。
十年后二十年后一部分元老承担着公司的运作，
离职的大家也散落在不同的公司，
都是像主程序员一样做着核心的事情。
所谓聚是一团火，散是满天星。

依靠流程、考核、规定去提升团队统计学意义上的生产力，
并不是从正面去解决问题的办法。
营造一个上进的文化，
就会让大家知道向东流一定能流入大海，
这样才能从根本上解决问题。
从团队的角度来说，
大家的总体生产力更加高了，
事情也更容易做了；
从个人的角度来说，
个人命运跟公司进程结合在了一起，
回报是非常可期的。

远见

在种田与爆兵中寻找平衡

战略类游戏中策略的选择，
往往会在两个方向中动态地摇摆：

种田。你的经济跟科技都会更好，长期发展更有优势，但是很容易短期内被打爆。
爆兵。你的战斗力会更强，短期战斗一定会胜利，但是长期看来非常疲软。

工程师团队做的事情其实本质上也是这两方面：

优化技术基建。
你的一切统计学指标都很好，也能支撑很大流量。
但是占用了太多业务开发的时间，你就没能有很大流量。
实现业务需求。
你的业务需求做的很快，用户的反馈迅速，他们非常开心。
但是技术债越来越多了，甚至你们还没做安全防护，一被 DDOS 就会挂。

这两件事情你中有我，我中有你，是动态平衡的。
不论是不做基础建设，或是万般皆下品惟有基建高，
都不是一个很好的情况，
工程师团队文化需要避免走向任何一个极端。

理想中的距离就是恋爱中的“刚刚好”，
业务需求不会因为工期而挤走技术基建，
技术基建也不会因为想练屠龙技就放弃业务需求。
两方都谦谦有礼，都说着：“你先请”然后让出了自己的位置……

不，醒醒，这样的情况不会发生。
除非事业发展停滞（公司要凉了啊），
在事业进展飞速的情况下，
业务需求永远都是层出不穷，
这种时候平衡点就化成了战略游戏攻略中的“随机应变”几个字了。
最终，团队会形成一种自调节的文化，
以实现高质量高效率的业务需求，
以及提前准备好足够牢固的基础建设 :)

活在梦里的感觉，有点真实。

其它

总的来说，
上面的个人、团队、文化是我从不同角度对工程师团队的理解。
但其实对于“道”的理解很多时候都是复杂的，
尤其是评价构建团队依靠的都是后验感知。

但总的来说，我很喜欢我们目前的团队 :)
而且我们强行达成了共识：
做对的事情，不论这件事情多难。

下面是一些有可能相关，
但又不知道怎么去抽象的话题，
就罗列在最后当一点散文的尾巴吧。

务虚与务实

最近有一句话又因为《新东方》年会的改编歌曲焕发二春了：

写 PPT 的不如讲 PPT 的，讲 PPT 的不如听 PPT 的。

Mia 去年升职为 Manager 以后，
也时不时跟我感慨，
她觉得目前工作中，
务虚的部分一下子多了不少，
感觉得更努力才行。

这很科学。

人在单打独斗的时候其实不需要太多思考，
依靠直觉去行动就行。
但是一个小队的队长，
就需要一些冠冕堂皇也好推心置腹也好的理由来说服队员们。
阿里巴巴这个级别的公司更是需要公司文化、价值观来维持组织的团结齐心。

而作为组织文化的实体表现者，
就会有到“越往高处，务虚越多”的感受。
有可能当你成为了一整个公司的领导者，
必须得确保自己的认知是可复用、能推广的，
从而你得务虚再多一点，再多一点，
最终化身成了公司的吉祥物，
然后公司大成功！

工作制度

早上九点上班，晚上九点下班，一周上六天班，真的好吗？

直接的问法是：996 接受吗？

虽然可以用很多论点去修饰，
但其实我核心的想法就是一条：
我无法接受强制的 996，
但是我是一个会自愿 996 工作的人。
具体的想法就不过多阐述了（现在半夜四点，我有点困意了）

我认为企业选择 996 的工作制度其实跟人类喜欢喝酒一样，
是市场充分竞争环境下的自然结果。
目前存在的问题是整个工作制度存在恶性竞争，
导致损害社会劳动氛围的可能性。
可以附加一些“额外工作医保要求”跟“高龄员工工时补偿”之类的来进行制度优化。

加班可以，常态不可以。
自愿可以，强制不可以。
健康可以，挂了就不行。

招聘

大纲里引用的句子是一篇七八年前的匈牙利网络文章，
当时我看的觉得蛮好玩的，
第一次以企业/资本的视角来看待员工。

招聘是一个很让人头疼的问题。

尤其是上面的文章中讲到了，
我的认知给自己立了一个 Flag:
“我只想招优秀的人。”

两年前写《HR就讨厌我们这样的技术》的时候，
我们招人的标准一句话总结就是
“希望候选人对口（做过 Python 的互联网后端开发），
又希望候选人优秀（有在项目里担当主程序员的潜力）”

当时招聘季 HR 把上海所有 Python 的简历都刷了一遍，
我们只给了 2% 的最终 offer 率，
于是 HR 锤爆了我们的狗头，
并警告我们：“上海的 Python 候选人池子被打爆了，你们考虑一下怎么办。”

于是（在引入 Java 技术栈之外）我们思考了“对口+优秀”这个标准之后，
拿掉了“对口”这个需求，
只想招“优秀（有在项目里担当主程序员的潜力）”的人才。

这个方案十分奏效，
我们去年新加入的队友都非常靠谱。
这也印证了前文对工程师团队文化的思考，
科学。

绩效

程序员是如今的热门行业，
热门行业的薪酬同样也是热门的话题。
（就像工业革命时的工人待遇一样）

作为一个好奇宝宝，
我也在《一次有意义的吹B》，
《培训三月，月入上万？，
《公司文化、工资期权、开发体验》中多次聊到这个话题的细节。

从更高的认知角度上，
我确认并坚定了我从毕业以来的观点：

只要维持每年的进步，
人的生命会是指数上升的。
你如今的成就，
不过是你十年后的成就里的繁星一点。

就像唐代斯在最后赠给马克西米连的“等待与希望”一样。
我的朋友，作为工程师的我想送给你两个词，
它们饱含着“递归”、“复利”乃至“宇宙膨胀”的内在哲学：
思考，坚持。

（全文完）

积极面思考

Wed, 23 Jan 2019 23:25:20 +0000

最近半年对方法论的思考比较多，
所以可能写的都跟“术”关系不大，
而更加偏向于“道”一些。

引子

我记得中学历史课本中，
在很前面的显眼位置上，
写着这么一句李世民对魏征的评价：
“夫以铜为镜，可以正衣冠；
以史为镜，可以知兴替；
以人为镜，可以明得失。”

这句话就像图书馆的闭馆铃声一样，
总会在深夜让我抽离自己的身躯，
以一个更高维的角度看自己、看别人。

就像在《写程序的我的性格》跟《毕业三年的报告》里面我自己反复念叨的一样，
工作很容易让没有防备的人类变成自我重复的机器。
前阵子跟一个产品的好朋友聊天，
讲到招人的喜好，
他说他只喜欢那种“工作经验大于工龄”的人。
或者换句话说，“工作的效率比大部分人都要高”的人。

在我看来，成为一个效率比别人高的人并不难。
其中一条很有效的办法，我称之为“积极面思考”。

什么是积极面思考

简单来说，就是从事情的正面去思考问题。

比如举个有点小众的栗子。
蓝猫的配音演员是葛平，他曾经也陷入过跟六小龄童一样的恶搞文化中心里，
但他既没逃避也没斥责，而是“放下了身段”跟恶搞他的大家玩成了一片。
最终大部分恶搞的同学都“路人转粉”，尊称他为“葛叔”了。
同样的道理，只要六小龄童老师能跟“六学家”们打成一片，他的风评也会再次走高的。

再举个工作中的栗子。
工作里少不了的事情是协同合作，
而多人协同合作容易导致“因为沟通的问题影响到了事情的进度”。
遇到沟通所产生问题的时候，
不论是文本化记录结果、寻求拍板人甚至是自己多做一点减少沟通的量，
都是有效的正面思考问题产生的行为。
而像分责推锅就并不是从事情的正面去思考问题了。

当面对问题的时候，能不怕问题，
不用懒政跟拖延去推迟问题的解决时间，
而是从解决问题的根本去思考、行动，
这就是积极面思考。

为什么要积极面思考

积极面思考是解决问题的捷径

我司有一点“中国互联网公司的通病”：微信办公。
之前我还在做B端业务的时候，
我微信里工作群有 300 多个，
基本上是周六正在跟女朋友约会，
然后突然就被拉进了一个微信群处理问题，
因为这点我还成为过电影院里看手机的我眼中的“无素质人群”。

当时我非常崩溃。
一方面我是作为工程师招进来的，却要做售前、售后、客服的工作；
另一方面由于我平常写代码写的最多，也很好说话，
并不是 Leader 的我充当着实质上的项目经理的角色。
当时有次周六凌晨三点，刚处理完事情的我发现CS同事二狗也在线，
我问他在干什么，他说周六我们的餐饮客户搞活动，他还要录十几个营销活动…

当然，别看我说的这么崩溃，其实我心里非常愿意呢。
假如一家公司是做企业级服务的，那么只要这家公司想要变得卓越，“客户第一”就一定在公司的核心价值观里。
之前《最近跟女朋友的周常》里也讲到了，“客户第一”是需要公司跟员工一起努力达成的。
所以虽然我一开始奉献出了周末（忙的时候连一周一休都做不到）
但随着操作手册的建立、流程的规范还有持续的功能更新，
后面的事情越来越顺畅了。

这件事情给我的附加感受是，
我真正地体会到了从开发者、项目管理者、用户的不同角度去看一件事情的全貌。
而且我确认了一个事实：
多方合作中，是能找到共赢点的。
只要想明白了这个点，事情就一定可以迎刃而解。
这就是所谓“积极面思考是解决问题的捷径”。

积极面思考是正向循环的关键环节

一般语境中，区分内向型人格跟外向型人格主要是用沟通意愿区分的。
但我偏向于另一种区分方法：
外向型人格与人沟通会回复精力；
而内向型人格与人沟通会消耗精力，他们靠独处来回复精力。

Mia 曾经评论过我，说我有一个内在的自给自足的循环，
是这个自洽的循环给我提供了活下去的勇气（听起来怪怪的…）
没错，积极面思考在我看来是正向循环的关键环节。

人的正向循环是依靠认知、行动、反馈的每个环节去自洽地形成的。
其中行动、反馈的过程跟结果都很难去控制，
所以认知就是达成正向循环的关键。
积极面思考会带来更正向的心里暗示，
而积极的行动也会潜移默化地改变所处的环境，
从而最终加大正向反馈的可能性。

多让座、多说请跟谢谢、礼貌待人其实都可以划入这个理论的范畴里。

积极面思考能扩大影响力

人类的潜力是无穷的，
然而大部分人类都会浪费它。
Zen of Python 里也说过：Now is better than never.
正面去思考问题并作出应对可能会比较难，
但不论是个人还是集体，
选择正面去迎接问题是长远的最优解。

就像 Fate/Zero 小说里的亚历山大大帝一样，
他最充满魅力的一点就是他的王道。
他的伙伴韦伯也因为跟亚历山大的思想交流，
而改变了一生的道路。

综述

总的来说，积极面思考能解决当下的问题，
也能带来长远的进步和影响力。
假如作为读者的你愿意的话，我非常推荐你尝试一下这样思考问题。

当然啦，光是思考是不够的，也要有对应的行动哦。 :)

（完）

回首看向2018年的OKR

Tue, 22 Jan 2019 22:07:02 +0000

去年默默践行了一年的个人 OKR,
今年年初也是到了回顾的时候了。

引子

去年写《这就是我2018年的OKR》的时候，
我刚处于一个从各类渠道学到了这个技巧的兴奋期，
所以非常激动地设下了（自以为）很精妙的几个小目标。

一年下来，我收获不小。
其中感触最深的一点是坚持自我审视对个人成长的有效帮助，
或者换一句话说，叫“坚持的力量”。

OKR 这种东西，就像小学生对以后职业的幻想一样，
是即美好又容易幻灭的东西。
最关键的并不是目标是怎么定的，
而是定目标的人是如何去认知他的目标的。

举个栗子，我给自己定下的年度目标有一条是“帮助陌生人 50 次”。
这点让我在路上走路都走不安稳了，一直左顾右盼看看有没有哪个人需要天降帮助的。
（最终顺带完成了不少把垃圾捡起来丢到垃圾桶里的普通成就）

回顾

去年定下的 OKR 是这样的：

O1. 技术影响力大幅度提升
- 学习/理解/使用/掌握6个技术工具
- 成为1k+ star项目的主contributor
- 技术文章输出20篇
- 自己有233 star以上的代码项目
O2. 事业上做出极大贡献
- 团队的OKR完成率在80%以上
- review 10万行代码
- 当300场面试官
- 成为整个团队top 1%的人
O3. 保持幸福度爆满的状态
- 与亲人总语音时间超过1000分钟
- 跟女朋友争吵次数小于3次
- 帮助陌生人达50人次
- 新增500首红心歌曲

很简单，分三点来看就行了。

技术影响力

技术影响力这点上，其实跟我设想的方向有很大出入，
主要原因是：我 2018 年一整年负责的都是一整个团队，而不仅是只要对自己负责了。
一个很大的区别是以前我可以非常活跃地抢锅，
然后在第一线的业务技术锻炼中获取直接经验，
并且快速升级。
现在很多时候是得适度地分锅，
然后让队友们在第一线的业务技术中去锻炼，
以让不同诉求的同学都能找到个人跟公司的平衡。
于是在目标 (Object) 的方向上产生了偏差，
关键结果 (KeyResult) 上的完成情况就偏差更大了。

技术工具上我一整年接触的比我想的要多了很多，
不仅对语言框架库 (Python/Django/ZeroMQ) 有了更深入的使用，
还对项目进度合作甚至向上向下的管理有了更进一步的认知。

而在公众输出上，由于一年的闲暇时间基本都奉献给了我的事业（指工作），
所以开源上今年只自然增长到了 200 个 star，
一年下来文章也只写了 18 篇，
总的来说，这一项给自己打个 70 分吧。

事业贡献

我认为 2018 年在事业上的投入带给我的回报是非常大的。
虽然一整年下来，部门的事业没能坐上火箭，部门的兄弟们也没能升职加薪苟富贵，
不过目前看来，我们的未来仍然是非常可期的。

从付出的角度上来说，Review 10 万行代码是肯定做到了，
光是近半年自己写的代码就有一万多行。
300 场面试官也已经达成了，
不过这个 KR 其实定的不好，
因为它的实现完全是依靠公司招人的计划以及跟 HR 小姐姐们的努力看简历有关的。
关于团队的部分没办法找到一手数据去查验，
不过我最自豪的一点是我们团队的大家一致保持着非常高的研发标准，
没有破窗效应，而且气氛还很棒，让我很喜欢在这里工作。

而从收获的角度上来说，我收获最多的就是各类的间接经验。
不仅包括技术选型、团队合作的一些实验、项目管理工具的实验，
还包括我跟听了一整年的产品团队的需求分析、设计回顾甚至是跟创始人的战略制定。
假如以前的我只对“从零到一”很有信心的话，
现在的我对“从一到十”乃至“从十到百”也一样充满着信心了。

总的来说，我其实在这个目标上付出的最多，
对应的收获也是最大的。

幸福度

其实当时 OKR 里面加这一条，
我有种“小意思，加上让大家看看吧”的轻蔑的想法。
人只要知足，就很容易达到幸福的状态。
当然，一年来的事实也验证了我的想法。

刚开始去实践目标的时候，
我逐渐又意识到了一点：
“人心所想会在潜意识里发出回声。”

比如我给自己列了一条“与亲人总语音时间超过 1000 分钟”。
这是什么意思呢？
刨去过年，一年大概有 50 周。
假如每周都跟家里打电话的话，
每次通话时间保持到 20 分钟就行了。
于是当时我周常给家里打电话的时候特意留意了一下，
得出了一个让我一愣的结论：
“不去主动接话题的话，跟家里的通话是聊不到 20 分钟的。”
就像鸡汤里说的那样，亲情就是这么遥远又纤细的一根电话绳啊。

总的来说，幸福度这个目标的完成状况我很满意。
年末我的网易云红心也成功地涨到了 2500，
并且给我一种我把云村听穿了的感觉。

未来

认真地过了一遍去年的 OKR 以后，
感觉时间这种东西，
食用起来的确是非常的美味。

今年的目标我还没想清楚，
不过有一点应该是不会变的，
多写文章，记录自己的思想，
然后产生白底黑字的回音。

毕竟永恒的方法，
就是刻在石头上。

（完）

如何搭建个人的舒适工作环境 —— 又名 Surface Pro 使用感言

Tue, 04 Dec 2018 23:16:29 +0000

首先感谢 Mia 在预算见底的年底，
卖掉了 iPhone 给我补上了款项…

这篇文章大概会涉及三个方面：

Surface Pro 体验
我的开发环境硬件搭配
我的开发环境软件搭配

Surface Pro 体验

我以前B站就逛逛动画区跟鬼畜区，
前几个月开始逛科技区跟生活区以后，
草单就像猫刨过的卫生纸一样疯狂变长。

在很多件很有科技感的物件中，
我看中了 Surface Pro。

码字时的桌面一览

Surface Pro 是微软出的一款平板电脑。
我看中的是 Surface Pro 6，
硬件参数是 512GB SSD 硬盘 + 16G 内存 + 8代4核i7 CPU (i7-8650U)，没有独立显卡，没有风扇，
除了支持触屏以外，身上的接口包括一个音频口、一个雷电2（兼容 miniDP）接口、一个 USB 3.0 接口、一个 Surface Connect 充电口。
国行官方售价是裸机 14888 RMB，
图里的键盘售价是 788 RMB,
粘在屏幕左边的触控笔是 728 RMB.

上面数据有点冷冰冰的，
让我们举些具体的栗子：

机身很轻。机身重量是 700g, 背在书包里感觉仅等于背着半本《算法导论》。
抱着走非常方便。配合 XODO/Bamboo 等触屏应用使用可以完全无纸化办公，连跟候选人聊天都是带着看简历。
- 而且记的笔记天生就是电子版这一点非常开心
- 怪不得用 iPad 的@快雪初晴会整天想写点什么
不会想用 Surface 玩大型游戏。没有独显让我连 dota2 都不想装。
- 然而我还是装了 Artifact 跟文明 6。
- 玩文明比想象的要流畅很多，标速一百回合内无明显卡顿。
- 不过就是比较烫，比得上边充电边阴阳师的小米 MIX 了。
工作时不会有任何卡顿感。16G 的内存同时开着 Chrome + JetBrains + Music 完全无压力。

开发时的常见内存占用

总的来说，购入 Surface 以后，
我用它替换了之前用的公司神舟电脑。
目前还在蜜月期的我回家也会背着这个小本子。

我的开发环境硬件搭配

我对硬件开发环境的需求大概是这样的：

公司和家里都得有舒适的开发环境
- 我回家一般也会写点小代码
公司的配置得更好一些
- 工作日我一天大概要睡 8 小时，剩下 12 小时在公司，4 小时在家。
- 一周在公司写代码的时间占比更高。
显示器得多一点，键盘鼠标得满上
- 我不太习惯单屏切多桌面
- 俗话说的好：越菜的程序员键盘越大
- 来自广东，就是粤菜

程序员的桌面

电脑（主机）：Surface Pro
- 公司的标配是当年的 Mac Pro
- 我自己要了个神舟，现在已经还了回去了
显示器：Dell U2417H * 3 + 显示器臂
- 公司的标配是俩，自己又补了一个
- 显示器臂我买的乐歌+NewBalance, 感觉 NB 便宜些质量也还行，全买 NB 也 OK
键鼠：Cherry 青轴 + 牧马人
- 键帽是一套无刻的高帽，@hulucc 买错了匀给我的，很好用
- 牧马人是淘宝活动 5 元买的，因为我用 Vim 所以用的不多，也很好用（滑稽
配件：Surface Dock + Bose QC 35II + 小米排插/数据线
- 值得拿出来说的就这几个
- Surface Dock: 官方的拓展坞，只占用一个 Connect 充电口，供给了两个雷电2四个USB一个网口，插拔极度方便！一键下班不是梦
- Bose QC 35II: 属于洗碗机类需求，用了就回不去没降噪耳机的时候了
- 小米排插/数据线: 性价比高而且实用，假如是自己买的话强烈推荐（我这是公司配的

最后是价格环节：

Surface 裸机 + 键盘是必备的，算上笔一整套大概是 16000 左右，京淘等活动期可能会有优惠，学生也可以买官方的九折教育套餐。
Dell U2417H 是 1.5k 左右，显示器的话看个人偏好。前阵子看到个干货：《如何选购显示器》
键鼠耳机就略过了，Dock 的话官方价要 1.5k, 假如你有多屏需求的话是必买的

可能整套看起来是很特么贵的，
但是可以一件件地慢慢攒啊 :)

我的开发环境软件搭配

距离我上次写的《搭建舒适的 Windows 开发环境》已经过去了快两年，
现在再去 review 当时的开发环境，
发现我用的软件基本上都换了一圈…

不过不论在什么平台开发，
用什么软件提升生产力，
我认为总的原则是不会变的：
聚焦目标，提升效率，减少重复

两年前的我主要面对的问题，以及解决方案有这么些：

安装软件不方便：用 chocolatey 去自动化安装
切换程序/寻找文件不方便：用 wox + everything 来定位
需要在类 linux shell 下工作：用 git bash 作为工作的环境
有很多一定要在 linux 下才能做的事情：用 virtualbox + vagrant + putty 的本地虚拟化解决方案
提升工作体验：使用 网易云音乐 + 有道云笔记 + 有道词典
想成为一个有理想有追求的人：用 Vim

现在我面对的问题跟解决方案，相较于两年前都有些许不同：

安装软件不方便：手动安装
- 本质上这是 Windows 混乱自由的生态导致的，很多软件都无法被 chocolatey 支持（比如 Steam
- 即使是用 scoop 或者是 choco 支持的软件，也会因为每个软件有些微不同的配置，而产生让强迫症不爽的自动化安装体验
- 所以现在我选择手动安装所有软件。其实感觉还行，因为电脑里也不会装上千个软件…
切换程序/寻找文件不方便：用 listary
- listary 的功能已经完美覆盖了 wox + everything 了
- 对中文的支持也非常好

需要在类 linux shell 下工作：用 Hyper
- git bash 一点不好的就是它太丑了，我配了好久都没配出好看的感觉
- Hyper 我用的主题是 hyper-akari, 是一个我非常喜欢的 CSS 魔法哥的作品
有很多一定要在 linux 下才能做的事情：那就去 linux 下做吧
- 目前做的后端是可以完美跨平台开发测试的
- 对于特定的功能会用 fake/mock 给滤掉，不妨碍开发体验

至于其它的体验上的软件，
就属于见仁见智各取所需的事情啦。
最后附上一些我的小习惯：

统一管理所有软件的配置，都放在了 github.com/LKI/LKI 里面。
在统一的 workspace 下放代码（我用的是 C:\Code）
用 ss + Proxifier + SwichyOmega 实现复杂规则下的科学上网。
:wink: 用 Vim

（完）

技术人员要怎么选择自己的职业发展道路

Thu, 25 Oct 2018 23:35:26 +0000

这篇文章的灵感来自于最近的一次跟好友聊天。

临近毕业的时候，我要找工作了。
但是当时的我其实非常懵逼：

我没有职业发展规划，我甚至连我想进什么样的公司都没偏好（反正我只能写代码）
就算我有偏好（比如钱多事少离家近），我也不知道哪个公司符合我的偏好
即使我知道有这样的公司（比如我想象中的谷歌），我也不一定能进
网上/生活里别人关于职业发展的说法五花八门（比如写代码是吃青春饭），甚至还互相冲突

于是我秉承着车到山前必有路的快乐心态，
去了第一家给我发 offer 的公司。
（结果工作出人预料地鱼块，详情参见《前文》）

如今的我再回头去审视这种青涩的想法，
我最大的感慨是：
信息量的多寡，的确是决策好坏的决定性因素啊。

我觉得当时我的懵逼是完全正常，
而且我的决策机制（去第一家合适的）也是没有大问题的。
因为我现在是这么想的：

没有最佳策略，只有你最赞赏的策略
不仅要靠自我奋斗，还要考虑到历史的进程
目标往往不是一开始就定死的，而是要不断更新的

没有最佳策略

人在面对选择题的时候，
总想找出正确答案。
但不是所有选择都是选择题，
总有选择是没有标准答案的，
这个时候人就会想选C。

比如职业相关的话题，
总会出现这一类问题：
“是去大厂比较好？还是去创业型公司？”

的确，在信息量不足的情况下，
这种问题是非常难以回答的。
Richard Liu 有一篇写的蛮好的文章《职场抉择：我适合大公司，独角兽，还是幼角兽？》就是讲这个话题的。

这几种公司的优点代表了不同的策略：

创业公司：机会极多，非常自由，事情做成的话成就感巨高。适合适应能力强，想独当一面的人。
独角兽：未来可期，各方面都比较优秀，团队水平会比较高。适合业务能力突出，想快速成功的人。
大厂：发展稳定，社会影响力大，工作不会侵占过多个人生活。适合在意公私平衡，想稳定工作的人。

比如有朋友跟我聊过他的跳槽策略，
就是挑着C轮/D轮的独角兽公司去，
只要趋势不变的话，
一两年公司就可以上市，
然后再过两三年期权就可以套现。
这样他就可以用他优秀的工作技能，
获得不错的报酬。

不过我个人来说不会选择这样的策略。
我认为人类的事业感受可以分为这么六个方面：

报酬：劳动获取的劳动等价物（钱）是否满意？
业务：对做的事情本身是否有成就感？
体验：工作的体验（环境/制度）是否舒适？
发展：工作内容是否稳定？对工作的未来是否有期待？
生活：与工作交叉的人生（通勤/假期）是否舒服？
团队：跟一起共事的人是否开心？

最理想的工作，就是这几个问题的回答都是正面的。
不过很多时候看到这样的问题，
感受到的反而是一种无力感：
我的工作对我影响很大，但很多地方好像无法改变。

这就对了，就是这样的。

历史的进程

一个人的命运啊，当然要靠自我奋斗，但是也要考虑到历史的进程。

这句话很多人都听过，是江学长视察联合工程公司的时候说的。
有一个我经常举的栗子，道理也是类似的：

一个人的发展，其实是乘法原理导致的。
蚍蜉和大树是很好的朋友，
蚍蜉在 Hooli 的广告部门工作，经常划水；
大树在 PiedPiper 的业务部门工作，朝九晚十，一周六天。
一年下来，Hooli 稳定发展，增长了 20%，
广告部门增长更快，增长了 50%，
蚍蜉有点划，其他同事评分都是 A，就他是个 B。
而大树呢，工作认真，贡献突出，个人评分 A++，
但是 PiedPiper 今年业绩一般，只增长了 5%，
大树所在的业务部门更是业绩下滑了 20%。
结果 Hooli 因为发展快速，蚍蜉都成了个小 Manager 开始带人了；
而大树所在的整个业务线都要被砍掉裁员。

用优雅的数学来归纳这个粗糙的故事就是：
个人的成长 = 个人 * 团队 * 公司 * 历史的进程。

就像很多独角兽公司都会引用的那句话：

if you’re offered a seat on a rocket ship,
you don’t ask what seat.
You just get on.

– Eric Schmidt

所以假如有机会的话，
在面试一家公司的时候，
去跟你未来的队友们聊一聊吧。
初创公司的话，看看创始人是怎么样的；
公司分了不同的部门以后，看看部门Leader是什么样的人；
扁平化的工作氛围，就跟（潜在）未来的队友们聊聊。
在合适的氛围、优秀的团队里，
个人的成长会有最大的加速度。

不断更新的目标

小时候想当科学家，
大学想当CEO，
毕业以后想当CTO，
面试的时候觉得当架构师不错，
入职了以后想想就当个后端吧，
现在觉得写好 Python 业务代码才是真切的目标。
以上就是“更新的目标”的含义了（并不

认真地讲，
我感觉在工作里除了具体技能的提升，
还有一部分很重要的是掌握信息量的增多。
在信息量不足的时候，
人类是很难做出最佳的选择的。
这也是为什么我们写程序的时候，
总会想问清楚“需求是什么？”“以后业务逻辑可能会怎么变？”
随着信息量的增大，
人类总可以做出合适的决策。

所以其实接触工作的过程，
其实也是一个人不断扩充信息量，
然后根据掌握的信息，
不断修正目标的过程。

总结

所以对于主题“技术人员要怎么选择自己的职业道路”，
这篇文章客套地讲了一些虚的道理：

选择合适的策略来找到心仪的公司
注意工作的团队也是非常重要的
在信息量增大时，及时更新目标

emmmmmm, 感觉这里的道理有点太虚了。
那我们就在接下来的文章里讲一些具体的干货吧 XD
祝大家都能找到自己心仪的事业，并且为之奋斗一生~

（完）

2018 QCon 第一天早上参会有感

Thu, 18 Oct 2018 18:54:24 +0000

其实这次的 QCon 一共有三天，
但是我只去了半天。

前几个月 QCon 临近，
老大豪气干云地一挥：
“今年我们买票去听 QCon！”
于是我们非常开心地到网站上一看，
一张票几千人民币…
……
预算不多的我们只能在力所能及的范围内买一些票，
然后把每张票拆成好几块，
让尽可能多的同学都去感受一下“全球软件开发大会”的氛围。
（QCon 的中文名真的是叫这个！）

这次我就去听了个早上，
在主会场彭蕾/臧秀涛致辞以后，
听了三场讲师的分享。

Java API Design Best Practices

第一场本来是个老外讲 Go 的，
但好像路上堵车没能来得及到会场，
所以临时换了个讲 Java 的老外。

这位老哥叫 Jonathan，
呆的公司一路是 Sun/Oracle/Microsoft，
介绍完自己以后，
PPT 突然切到了 <Effective Java (3rd)>,
然后 Jonathan 吹了一波：
“这可是写 Java 的程序员都必看的一本书！”

然后话题逐渐切入正轨，Jonathan 提出了好的 API 会有的几个特质：

易懂的 (Understandable)
稳定的 (Consistent)
合适的 (Fit for purpose)
文档好 (Well documented)
节制的 (Restrained)
可进化 (Evolvable)

然后 Jonathan 用具体的例子穿插着讲了一下他对这几个特质的理解。

我听下来感觉抛去具体的语法例子，
优秀的 API 特质都是共通的，
就像之前写的《优雅的 Python 接口设计》一样。

最后 Jonathon 又吹了一波，
并且还极力宣传说：“你们这些只看过第二版的，记得买第三版看看啊…”
简直让人怀疑这本书给他分成了（x

腾讯微服务架构的过去、现在与未来

休息了一会儿，就到了腾讯讲师刘昕的回合了。

虽然话题是微服务框架，
但是感觉大部分时间刘昕都在宣传自家框架 Tars (github.com/TarsCloud)…

不过整体讲的逻辑还是很清晰的：

最早遇到了业务逻辑复杂、代码质量难控、运营管理混乱、监控体系缺失的问题。
后来在“大系统小做”的指导思想下，逐步开始统一框架。
框架是首先实现了服务调用+服务治理的基础功能。
然后提升了性能+易用性。
现在还引入了容器化+高拓展性（其实到这一步就可以开源推广了）

刘昕用的 PPT 里有两个很好玩的数据。
一个是 51% 都考虑往 Cloud Native 的架构转。
这个数据引出的话题是一个很不错的话题，
让 AWS 重度用户很想说些什么，
感觉下次可以专门码一篇文章。

还有一个是用服务治理/多语言的不严谨划分成的四象限：

非常有趣。

最后刘昕还花了不少时间讲了一下 TARS 支持的多门语言。
听了以后我很佩服（然后选择了 service mesh…）

The Past, Present, and Future of GO 2

休息了一会儿后，本应第一个开讲的 David Chaney 终于来啦。
（@hulucc 问：他跟 Go 啥关系啊？
@紫月酥答：应该就像 @jkzing 跟 VueJS 的关系一样，是核心 Contributor。）

一开始 David 讲了很多历史，
比如 Go 诞生的初衷，
Go 从小长大一路走过的路，
软工和编码的区别，
Go 多个版本的更新，
现在用 Go 的公司/团队/项目之类的…
听得我感觉又是一个典型的布道师，
就当是给纯萌新科普 Go 了…

然后！
David 突然又介绍了一波 gopher 这个萌物：

（感觉全场一下子就四老外兴奋.jpg起来了）

在漫长的铺垫以后，
David 终于讲到了 Go 面临并且要解决的三个大的问题：

依赖管理 (Dependency management)
错误处理 (Error handling)
泛型 (Generics)

听到这里，我一拍大腿：
“对对对！我当时就是因为这个弃坑的！”

随之 David 不紧不慢地用各种小例子给出了目前的解决方案：

Go 1.11 里已经可以用 go modules 来管理依赖了。（初见的我有种 node_modules 的熟悉即视感）
Go 2 里会引入 check/handle 等语法糖来处理错误，本质上还是要第一时间让程序员自己处理错误的
Go 2 里会有泛型，目前可能会引入 contract。（但具体怎么搞，我感觉我这里没太听明白，之后得去深入看看）

而后 David 还特别强调了一下，
Go2 和 Go1 只是大版本不一样，
“是不会像 Python3 或者 Perl6 那样滴…”

感想

主会场第一天上午到此就全部结束了。
整体下来，我感觉对眼界增长大于技术收获。
可以知道同僚都在朝着什么方向去深耕也是非常不错的收获。

2018年的最后一个季度肯定会再次把 Go 给捡起来认真玩一下…
（不过没有参数默认值真的写起来很难受啊.jpg）

（完）

优雅的 Python 接口设计

Fri, 21 Sep 2018 20:57:46 +0000

今天跟@hulucc 日常写码吹比，
讲到了选第三方库的原则说：
“我其实发现我现在选库不太 care 他源码是怎么实现的，
但是我非常喜欢那些 api 设计得巨科学的库。”

科学的 API

API 设计的科学大概是什么样的呢？
比如举一个有名的例子就是 requests 这个库。

Requests is one of the most downloaded Python packages of all time,
pulling in over 11,000,000 downloads every month.

这个库的 API 用起来大概是这样的：

>>> response = requests.get('https://api.github.com/user', auth=('user', 'pass'))
>>> response.status_code
200
>>> response.headers['content-type']
'application/json; charset=utf8'
>>> response.encoding
'utf-8'
>>> response.raise_for_status()

这里设计的所有 Python 程序语言都是见文知意的英文人类语言，
requests.get 中的 requests 不仅是包名，
还化身成了代码语义的一部分。
返回的 response 就是一个典型的 HTTP 协议对象，
只要对 HTTP 协议有一定了解的程序员，
基本上不用看文档都能猜到它的主要属性和相关作用。
对应还有便捷的 .raise_for_status() 和 .json() 这样的常用方法。
这就是科学的 API 给我的感受。

当然，库的作者（也就是那个帅哥 Kenneth Reitz）也清楚自己的代码接口优雅，
他的个人签名也是这么说的：

I wrote @requests: HTTP for Humans.
The only thing I really care about is interface design.
– Kenneth Reitz

不科学的 API

大部分开源高星项目的接口都是比较优雅的，
那么不科学的 API 大概是什么样子呢？
唔，我的话，翻一翻自己两三年前的代码，
就满是不科学的 API 实现了。

最早接触 **kwargs 这个东西的时候，
我非常喜欢用这个语法，
比如我常常会写这么一种函数：

class Record:
 def create(**kwargs):
 now = kwargs.get('now', datetime.datetime.now())
 key = kwargs.get('key')
 value = kwargs.get('value')
 ...

这样写的好处是看起来灵活的一比，实现起来爽。
以后假如要加参数，
往往只要在 record.create 里面加一个新的 kwargs.get 就行了。
然而在大部分情况，这样的实现只会把参数给隐式化：
记不住参数调用 record.create 的时候还得进函数看实现；
而且万一把 value 拼错成了 valeu，
函数是会像某些语言一样正常运行的！
然后会在后面某个地方报错，
这样就很难方便找出根源了。

后来我大部分情况会这么写：

class Record:
 def create(now=None, key=None, value=None):
 if now is None:
 now = datetime.datetime.now()
 ...

这样的显式调用强制要求参数的正确性，
虽然实现起来要写的参数多了，
但是调用和阅读的时候更加明确。

>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

后来我看到 The Zen of Python 的这句 Explicit is better than implicit 总会想到这个例子。
（关于 Python 接口参数设计的，有一篇我觉得说的很好的知乎文章：
《Python函数接口的一些设计心得 - 灵剑》）

例子

The Zen of Python 里还有非常多珠玑可以挖掘。
比如在做的一个项目 hutils，
想着把公司里各种 Python Web 中常用到的函数抽出来做个基础库，
结果写的时候 80% 的时间都在想怎么让 API 变的更科学。

比如我们写后端的时候，
经常会遇到要转化框架错误类的情况：

def service_call(...):
 try:
 external_service.call()
 except ExternalServiceError as ex:
 log_error(ex)
 raise APIError('Error calling external service')

对应的，我们会有个这样的装饰器来封装错误处理：

@contextlib.contextmanager
def catches(*exceptions,
 raise_to: BaseException = None,
 raise_from: Callable[[Exception], BaseException] = None,
 log=False,
 ignore=False):
 try:
 yield
 except exceptions as ex:
 if log:
 log_error(ex)
 if not ignore:
 if raise_from:
 raise raise_from(ex)
 else:
 raise raise_to # pylint: disable=raising-bad-type

有了封装的装饰器以后，
简单的错误转化就可以跟业务代码相分离：

@catches(ExternalServiceError, raise_to=APIError('Error calling external service'), log=True)
def service_call(...):
 external_service.call()

但是这样的装饰器实现会在 Code Review 阶段就会被像 @hulucc 这样的铁血队友锤回来，
这样的 API 实现有几个不够科学的地方：

raise_to 和 raise_from 有重叠之处，
而且调用者不注意的话会触发 raise None 的问题，
连 pylint 都注意到了。
应当使用类型判断来合并参数。
这样错误转化，原错误类的堆栈信息会丢失。
应当使用 raise ... from ... 的语法来保留堆栈信息。
transfer/ignore/retry 其实是相对独立的逻辑，
混合处理当然可以，
不过最好的情况是逻辑拆分，独立处理。

一波讨论以后，
顺带顺手支持 catches(Exception, raises=raise_api_error) 的快捷写法，
装饰器的实现就改成了这样子。

@contextlib.contextmanager
def catches(*exceptions, raises: Union[BaseException, Callable[[Exception], BaseException]], log=False):
 exceptions = exceptions or (Exception,)
 try:
 yield
 except exceptions as ex:
 if callable(raises):
 raises = raises(ex)
 if log:
 log_error(__name__, raises)
 raise raises from ex

感觉更加优雅了呢。

结语

Python 因为语法及其灵活，
所以其实接口的设计是全看程序员的设计水平的。
但往往科学又优雅的实现就像 There should be one-- and preferably only one --obvious way to do it 这句话说的一样，
是万中取一的。

不仅要实现功能，
还要优雅，不要污。
看来写程序的确是要想得多，
怪不得程序员会头发少呀 :)

（完）

毕业三年的报告

Sun, 09 Sep 2018 19:46:37 +0000

前阵子在知乎上看到一个问题，
叫《读研三年与工作三年的人有哪些差别》。
我的思绪突然被唤醒了：
对哦，原来我已经毕业了三年了。

注意，本文有一万字，可能要读个半小时？

我跟小米娅的工作习惯都比较类似，
前阵子闲聊的时候我们算了一下：
正常的朝九晚六加双休，
一周是工作 40 小时；
不过因为我们两个人基本上下班以后还会看工作相关的事情，
平均下来工作日会多工作 2 小时，
周末还会有一天干职业相关的事情，
所以满打满算可以说一周工作 60 小时。
嚯。也就是说我们工作两年，就有四年工作经验了。
赚翻了耶。

当然了，这个工作经验 buff 只是说着玩的。
认真地说，要算工作经验的话，
我更愿意从 2014年7月7日算起，
那是作为实习生的我第一份工作的 First Day（定语真多）。

实习

通勤

我们大学的设定是大四一年是给你实习的，
然后我因为硬学习成绩不算好，
考不动研也想早点致用，
所以抱着找一份实习工作，
然后毕业以后转正成为正式工的想法。

当时 QAD(一家美资跨国软件公司) 跑来学校校招，
我就去参加了面试。
面试的流程是笔试 + 群面 + 单面，
跟 NIMO (交大网管部) 的面试流程极为相似。

~~所以我熟练地就通过了。（并没有）~~
我其实填完了姓名和手机就愣住了，
因为第三个空叫“目标职位”，
有 SE, QA 和 BA 个选项可以勾选。
我便举手问了负责发试卷的 HR 小姐姐 Gloria，
Gloria 跟我说你软件学院的就填 SE 吧，
其它两个不用填，我就顺从地填了 SE。

后来我才知道要填职位是因为公司分工所致的：

QAD 在全球各个地方都设有研发中心，中国的研发中心设在上海。
当然了，上海其实不止有研发，还有销售、售后等等部门。
研发部门正式的说法叫 Research and Development, 写作 R&D, 读作 R and D。
R&D 按照业务团队拆分成了好几个小组，我在的组是 Release Foundation, 中文意思大概是基础组件组，人多的时候大概有 20 个人。
R&D 里每个组都是具有独立作战能力的，从技术选型、前端、后端到测试都是自己组内搞定。
所以其实我们组内就两种职位：SE(开发) 和 QA(测试)，BA 是更一线的业务相关开发组才会设立的职位。

在实习了一个月以后终于搞明白了公司分工这个问题，
我很是兴奋，因为我觉得这是公司的脉络。
一个公司能成长到跨国的程度，
那公司组织结构什么的肯定是科学的！
学到了，以后有一天我开跨国公司了，
我也这么搞！
我很开心地这么想着。

后来我才知道还有是按职能分工的制度。
不过我一直沿用了跟别人介绍公司时，
先介绍公司业务范围、
再介绍公司分工组成、
最后介绍团队相关技术内容的套路。
因为我就很吃这样的套路呀 :)

通勤

不过实习的时候有一点我很困扰的是，
公司在浦东陆家嘴软件园，
学校在闵行。
算上走路每天单程得两小时，
来回四小时就没了。

有些同学选择了在公司旁边合租了个房间。
不过我看了一下我的实习工资，
感觉付费上班有点亏，
就约着同在一家公司实习的李超一起每天 06:45 起床，
06:50 出门赶在 09:00 前到公司。

公司的学长学姐发现我们俩居然选择了每天四小时的通勤，
就开玩笑跟我们说：“你们这样肯定受不了的，两个月内你们肯定会租房，或者要么就离职了…”
感谢这个反向 flag,
实习的一年就算被挤扁在 5 号线的门上，
我也是坚持四小时地铁来回。
并且我还在地铁上补完了想看的动漫和想读的书。

《代码大全 (Code Complete)》这本书的中文版和英文版都是在地铁上读完的，
直至今日想起来也清楚地记得，
身边全是上班的社畜只能举起手机仰头读书，
而被书里讲的一段代码陋习深深地震撼到的感觉。

菜鸟

面试的时候，我问 Joe 说组里的开发环境是怎么样的？
Joe 跟我说：“我们开发语言是 Perl 和 PHP，平常都是在 Linux 上用 Vim 开发。你接触过么？”
我尴尬地挠了挠头：“Perl/PHP 只听过，Linux 和 Vim 都只是在课上碰过，根本不了解。”
Joe 安慰道：“没事，写写就熟了。我们每个人都会有一个 Mentor 的。”

噢 0w0，有 Mentor 啊，那我安心了，我心想。
在网管部我们也有 Mentor 这样的师徒制度，
一个明确的求助对象对新手来说是非常大的心理安慰，
当然最终的修行还是得靠个人的。

入职的第一天我早到了一个小时，8 点就来了。
结果前台 MM 还没上班，
我站在门外等了十分钟等到了给我开门的扫地阿姨…
道谢以后找到了挂着我工牌的座位，
然后发现我身后已经坐着一个看起来快 30 岁的工程师了。
看了看他的工牌是叫 Justin Zhang,
我十分好奇地问他：“Justin 你好，我叫 Lirian，中文名是苏子岳。你是我的 Mentor 吗？”
Justin 若有所思地回答：“算……是吧？”
（实际上就是的）

在做完了公司给新人的反腐败、反性侵等在线课程以后（没错…）
我摩拳擦掌地问 Justin 有啥我可以做的么，
Justin 说：“你去了解一下 Vim 吧。”
Emmmmmm, 还没理解这个任务的时候，
Justin 就打开了一个 Vim 的页面：
“我给你展示一下我们平常是怎么看代码、写代码的。”
然后 Justin 便向我展示了一下 Nerdtree/CTags 等各式功能，
并且帮我装上了他的配置 (schnell18/dotvim)…

于是接下来的几天，我除了公司的新手村任务，
还开心地到处看 Vim 相关的资料（没错，我甚至连 vimtutor 都还没跑。）
越看我越觉得 Vim 这个东西，
真的是像 Justin 说的一样：
“Vim 是一个非常强大的工具，你学 Vim 可能要一个月，但是你用就能用一辈子。”
一开始不熟练的时候，
我经常地就是 jjjjjjjjj 或者 i→→→→→→→→→ 这样操作，
不过由于 Justin 时不时会站在我身后帮我 Review 代码，
在压力和自尊心下，我就改成了 }} 或者 f2$ 这样的操作了…

我的 Mentor Justin 是一个代码洁癖非常重的工程师。
当时我们的项目管理是用 git + gitolite 管理的，
每次我们提交代码的时候，
Justin 都会用 git diff + vimdiff 来逐行 review 我们的代码。
有的时候需要在命令行敲命令，
Justin 也会站在我身后跟我讲一遍我要敲的命令。
并且以此我从 Justin 那学到了各种符号的英文说法，
比如横杠 (dash), 反引号 (quote) 等等…
（不过最开始每次 Justin 跟我说 git rev dash list 的时候我都会一愣并且反应半天）

忧虑

慢慢地，我习惯了用 Putty + Vagrant 搭开发环境，
用 Vim + Git 去编辑提交代码，
用 Perl 语言去解决业务问题。
但随着学到的东西越多，
我开始越来越担心自己不能变得杰出。

那阵子上下班看了不少技术相关的文章/书籍，
其中有两个思想异常地打动我，
一个出自《代码大全》：

关于程序员的经验：

人们还荒唐地强调程序员有多少经验。
“我们需要有五年以上C语言编程经验的程序员”就是愚蠢的说法。
如果程序员过了前一两年还没有学好C语言，那么再加三年也没有意义。
这种“经验”和工作效能关系不大。

我当时看到了这句话，
回头想了一下自己这两周的工作，
发现我其实只是在单纯地挥发自己已有的知识！
我并不想工作三年以后，
成为那种实际只有一年工作经验然后重复了两年的人类。

还有一个是我在上班路上想明白的。

我玩竞技游戏会非常累，因为我很想赢。
我想赢也不是因为我多么享受胜利的感觉，
而是我害怕我努力却没有回报的付出回报不对等的挫败感。
所以很多时候我做事情不会尽力，
因为这样即使打团打输了，
我也有理由想：“not my fault，我只出了八成力。”

但是还没毕业的我又想，
假如我真的选择了一条我不能尽力尽兴的人生道路，
那当我回首往事的时候，我怎会不因虚度年华而悔恨，也不因碌碌无为而羞愧呢？

于是我在自己的心理暗示环节中，
加入了“比你聪明的人也有比你努力的啊”这一个鸡汤环节。

转正

现实问题

在实习了一年以后，
我顺利地转正了。
我遇到了一个小难题：薪资。
当然，这里说难题并不是说公司为难我或者我不满意什么的。
首先我其实不太在意刚毕业的薪酬，因为我总觉得以后有一天我创造的价值会比我刚毕业一年的薪水还要多；
其次公司也不会压任何员工薪资，给的都是统一水平线的 offer。

薪资的难题难在我隐隐感觉有点不够用。
大学时候我一个月生活费大概是一千多一些，
非常够用了。
毕业以后假如我要在公司附近租一个带厨房的一室户，
每个月大概要 3500，扣除这么多房租和其它杂项我每个月能剩两千多一些。

当然了，正常的社会人肯定不会花这么多的占比来租房的。
但我想着我不烟不酒，不买衣服不吃大餐不社交，
回家要么看看技术博客要么玩玩游戏，
而且我女朋友也不是物质狂，
送不了贵的礼物就送点有心意的礼物…
讲道理省省也差不多够用？
于是我果断花了一半的月可支配收入在房租上…

后来毕业快一年了，
我爸问我：“
你妈妈毕业以后住在外公那里，
毕业工作的一年钱基本全都存下来了，
后来我们结婚你外公还把存的工资都发给你妈妈了。
你这实习加工作两年了，总是存了点钱吧？”
我：“……存了存了…哦我要去洗衣服了，先挂了，886”

那年我弟高考完去武汉读大学，
我打算送一个最新的 iphone 给他。
当时我去读大学的时候，
我舅送了我一部手提电脑 (Lenovo Y470),
收到礼物后，我心中充满了可支配的自由喜悦之情，
在 QQ 空间发了一条“我有自己的电脑了！开心的要哭了！”
我妈看到以后狠狠地批评了我：“有个电脑就这么没出息吗？快把这条状态删了。”
我：“……”
所以我弟上大学的时候，
我决定也让他体验一下这种可支配的自由喜悦 :)

在认真算了一下最新 iphone 的价格，
以及我几个月的财政状况以后，
我连续两个月都厚颜无耻地拉着女朋友去吃社会食堂，
并且只点一个荤菜，然后蹭女朋友的青菜。
在吃了两个月的社会食堂以后，
我成功地爱上了掌中宝这道菜。
有一说一，掌中宝是真的好吃。

Last Day

从实习到转正还有一件对我来说感受很深的事情，
就是 Justin 离职去了平安好医生了。

外企有一个充满仪式感的离职 Last Day,
在这天你可能会拿着一张 Checklist 一个个地做过去，
然后跟平常一起工作的同事聊聊工作上或者生活上的事情，
再发一封带有你个人联系方式的邮件给全上海再抄送平常对接的各种外国同事，
最后在所有 Checklist 都做完以后早点下班，
结束你在这家公司几年的雇员生涯，开始下一段的工作和人生。

我看文学作品，
最受不了两种剧情：
一种是美人、英雄迟暮；
一种是再见难的离别。

直到今天我也能想起 Justin 的 Last Day，
他早上正常地早到了快一个小时，
也正常地处理了事情，
中午组里的同事们正常地在楼下吃了个送别饭，
期间大家聊着以前、以后的事情。
下午四点多，
Justin 背着他的包，
声音不是很大地说了声：“我走了。”
然后大家都站了起来跟 Justin 告别，
在走道的 Justin 也停了下来，
笑容也一直停在了他的脸上，
直到转身离去。
我幽幽地感慨了一句：“Justin 要是再多站两分钟我感觉我都要哭出来了…”
顿时大家都忍不住笑了，
冲散了那股忧郁的离别气息。

其实大部分人都不会一辈子只做一份工作，
在 21 世纪的上海也是如此。
所以其实在职场的大家，
也很清楚身边的同事在某一天，
可能会因为各种各样的事情而选择离开。
大家对离职的同事也会抱着祝福的心情，
毕竟世界很大，生命更大，
总有机会再见的。

后来 Justin 走后的黄桃季节，
我们还是成功地照例蹭到了 Justin 渠道的美味黄桃 :)

本职工作

在 Justin 走后，
我逐渐接手了整个项目。
随着新的一年校招，
新的实习生们也来到了公司，
我也变成了一个勤奋的小哥哥 (@Ray) 的 Mentor，
我便像当时 Justin 教我一样教他 Vim、Review 他的代码。

在跟他交流的过程中，
恍惚间我看到了一年前我的影子，
间接地我对自己的理解更加深入了。
我好像很模糊地抓住了“该怎么样请教别人才能学的更快”、
“工作里要怎么发挥自主性比较合适”这样的概念。

具体在业务开发里，
因为团队人员配置一直比较科学，
而且大家效率都比较高，
所以我们比预期项目进度早了两个月就开发完了 Perl 的版本。
然后这里我很开心地找到了一个可以写到简历上的事情。

我很早就感觉到了项目会提早做完，
所以心里一直有个想法在摇曳：
“能不能用 Java 重写一遍这个 Perl 的命令行工具？”

当时用 Perl 是因为这个命令行工具初版用的是 Perl，
加上 Perl 本身非常适合命令行的文本处理，
以及我们组的开发对 Perl 非常擅长。
但是 Perl 的缺点也很明显：
这不是主流语言，很难招有经验的人，
新手又容易因为学这个看不到前途就加大离职风险，
而且部署上 Perl 的部署跟系统关系挺大，
我们还踩过一个 prelink 跟 Perl 冲突的坑。
相比而言 Java 可能在文本处理上弱了，
但是在人员招聘、部署上会方便很多。

不过做工程项目，遇到的很大问题就是性价比。
我们 Perl 版本的项目写了快一年，
算上单元测试代码量好像是五万行左右，
上线时间还有两个月，
看起来是不太可行的。
但是我们却把这件事情给做成了。

整个事情主要是因为当时我的 Manager: Joe 的魄力。
（就是上文实习时候面试我的那个人！）
我中间跟 Joe 讲过 Perl vs Java 的话题，
他首先非常认可我的观点，
并且跟我说关于工程项目上的问题他都可以想办法搞定。

于是我决定先自己在业余时间尝试用 Java 重写整个项目，
就算最后没用上也算是我练 Java 了。
那阵子晚上去社会食堂吃完饭加送女朋友上地铁以后，
我走路回家洗个澡就又赶回公司码代码。
因为熟悉逻辑加只是纯重构，还能抽象类加精简代码，
一个多月的时候我把整个项目的骨架加基本的单元测试都实现了。

后来一天 Joe 一看骨架都做好了，
于是很兴奋地拉上我们认真地合计了一下，
算了一下投入产出比，
归纳出来了 8 条英文的 “why should refactor from Perl to Java”。
最终 Joe 在跟各方协调沟通以后，
不仅用 Java 重写这个方案通过了，
我们还多了两个月的开发时间！（协商延期）
于是 Joe 又从组里其他项目抽调了好几个队友来一起开发到最终上线 :)

外国队友

因为我们的命令行工具最终部署是各种外国程序员用的，
所以上线前我的组织任务就是跟外国的队友接洽。
对接最多的时候是连续两周每天早上 09:00 ~ 11:00 都要在线跟外国同事 (@Mythily) 语音会议，
然后她会共享她的屏幕，
我看着她的 Terminal 跟她讲解各种命令 or 文档。

这个时候我突然就明白了为什么 Justin 会跟我说 “git rev dash list” 这样全英文的命令行读法，
因为我跟 Mythily 也只能这样说，
我又不可能跟外国人说 “ls 空格 -l 回车” ……

可惜由于学艺不精，
我很多时候也只能：
“emmm, let me send you the command line in chat”
“yeah yeah yeah, space”
“no no no, dash, yeah git dash”

不过还好 Mythily 是印度同事，
我们两个对有口音的英语的理解能力都超强，
沟通也很顺畅。

有的时候做完了一天该做的任务我们还会闲聊一会，
一次她还开心地跟我科普了一个印度传统节日叫 Diwali,
并且邀请我什么时候可以趁 Diwali 去印度玩。
我也礼貌地邀请她在 Spring Festival 的时候来中国玩，
展现了一定的大国风范。

业余技术

讲了很多工作上的事情，
一方面是因为真的上班在工作，
下班在思考，
睡前都在想代码要怎么写才比较优雅；
另一方便是真的穷，
平常的消遣就是看看 YYF 或者刷刷技术博客。

技术类博客有个网站我很喜欢，叫酷壳 coolshell。
酷壳的博主陈皓的状态就是我理想中的状态：
连续十几年都在技术的一线工作，
对语言、工具、架构、文化都有自己独到而优秀的理解，
对普通程序员有着不俗的影响力、引导着他们变得优秀，
至今仍奋斗在一线。

受着这样的博客启发，
我也决定开始自己写博客。
不过一开始没啥好写的，
我就列了一些解决bug的流程…

在写博客的过程中，我发现这是个很好的进步途径：
写博客不仅可以督促我苟日新、日日新、又日新，
还能时常提醒我去看看别人是怎么发现问题、认知问题、解决问题的。
至少这不会让我变得与行业脱离太多，
也说不定可以避免一年经验重复N年的问题。

变化

打击

有一天在黄浦江边上跑步的时候，
我突然接到了 Justin 的电话。
在聊了一下近况以后，
Justin 邀请我去他现在的公司平安好医生面试。
我思考了一下，
觉得去互联网公司试试也是不错，
而且 Justin 已经去当了前哨了，
公司应该是不错的，
我就高兴地去面试了。

然后崩了…

我去面的是 Java 后端，
于是面试官就问了我一些很平常的 Spring 框架/Java 线程池/GC/进程分析之类的，
结果我全都不会。
面试官也很无奈，
他就问我：“那你觉得你擅长一些什么？”
我弱弱的回答：“Vim？”
面试官想了想，问我：“把光标移到屏幕中间是哪个快捷键？”
我一愣，然后回答：“不知道……”
（后来查了以后才知道是 M，我居然真的从来没用过…）

后来我回来认真复盘过，
觉得面试我主要有几个问题：
一是的确菜，很多都不懂，不会不学不练；
二是过于自信没有准备，有些套路问题是可以先学习的；
三是没意识到写命令行的 Java 技术栈和写后端的 Java 技术栈是不一样的。
再加上面试没问算法题，
也没办法靠硬知识加分…

不过最终还是给我发了 offer，
只吃薪酬上比较尴尬，
是跟我当前工作没有涨幅的 offer。
问了一下 HR，说是因为我是毕业没满一年，
所以是按应届生来的。
我心有不甘，不过非常理解。
虽然我没面过别人，不过换我面一个问题都回答不上来的人，
能发 offer 已经算给推荐人很大面子啦。

面对着这份 offer，我开始纠结了。
理论上平薪跳槽不科学，
但是这可是互联网公司诶，火热的行业诶；
而且还有已知的大腿 Justin,
我跟着学总行了吧？
不过这么离开 QAD 总是心有不甘，
当时项目还没彻底完工，
而且不算实习的话工作还没满一年，
组里队友其实都很好…
emmm 纠结。

一般来说英雄电影里，
低落时总有前辈站出来给出指导意见。
于是我尝试在微博上私信给左耳朵耗子，
并且得到了他的回复。

然后我晚上跟皓哥电话聊了快两个小时。
电话里，他讲了他在亚马逊、阿里、自己创业的三段不同的经验，
以及他年轻时候类似的烦恼，
甚至还讲到他写代码解决问题时的方法思路以及对应的人生观。
皓哥给的建议是具体的，
那天晚上听在我耳中的却是非常理想主义的两个字：格局。

人生在世近百年，
作为工程师会解决无数的问题，
所以有的时候眼前的问题放得更长远会有更好的解决方法。
挂了电话以后，
我心中想起了一句俗话：“莫欺少年穷。”
于是最后我在跟 Justin 提前沟通好以后，
跟 HR 小姐姐婉拒了这份 offer。

（然后我每天都给自己打两升鸡血！）

普通的一天

后来有一天，百姓网的 HR (@PP) 从我 GitHub 翻到了邮件，
发了封邮件要到我的微信，
然后约了个早上的面试。
在拼多多的基友 FM 也问我要不要去面面，
我就也顺便约了个同天下午的面试。

早上去浩然面完百姓，
中午找 ldsink 在学校门口吃了个面，
吃完以后 ldsink 还顺路带我去他公司转了转。
刚走到凯利大厦时，一个同事跟 ldsink 打了下招呼，
我好奇地问：“这是谁啊？”
ldsink 说是一个销售同事。
我顿时感到十分惊讶：“你们这么热情的么？开发和销售都这么熟？”

到了公司里逛了一圈，
感觉这个小公司的确小的比较明显，
人也少装修也比较裸，
不过见到了 Eason Jiang 的前室友，
一个同济大学的瘦子，
世界真小啊。

晚上去拼多多面完以后，
跟 FM 还有 FHN 在公司旁边的面馆吃了碗面，
吃完都七点多了准备回家。
突然微信上 ldsink 问我吃完了吗，
他还说公司同事都没下班呢，
给我留了份盒饭，邀请我去一起吃…
我心想公司盒饭哪有外面面馆的面好吃，
不过还是跑过去了。

结果发现我去是面试的！
我两周前发给周丞的简历都打印好了…
第一个面试官是个看起来就事业有成的后端，
做了两道算法题聊了聊天就没了；
第二个面试官就是上文的同济瘦子，
啥都没问，纯吹比，我给他看了看我业余写的前端玩具，
他给我介绍了下产品相关就没了…
然后我坐着稍微等了一下，
公司的 CEO 居然专门从外面赶回公司来见我，
然后他问了一下我的技术理想，
我跟他说了一下就开始互膜起来了（还是带身体动作的那种互膜…）

回家以后我打电话跟女朋友说了下今天面试的情况，
并且我还猜测地跟她说：“假如都给我发 offer 的话，我应该会去再惠，这家公司给我的感觉很舒服。”

后来我的确去了再惠，
并且和一帮很强的队友一起共事。

当你老了，回顾一生，就会发觉，
什么时候出国读书，
什么时候决定做第一份职业，
什么时候选定了对象而恋爱，
什么时候结婚，其实都是命运的巨变。

只是当时站在人生的三岔路口，眼见风云千樯，
你作出选择的那一日，在日记上，相当沉闷和平淡，
当时还以为是生命中最普通的一天。

新的开始

自由

在16年11月底，我从一家外企来到了一家A轮的互联网公司。
在逐渐熟悉了业务和技术以后，
我突然意识到了很多以前习以为常的东西其实是每个公司都不一样的。
其中让我感触最深的就是公司制度。

比如说工作范畴。

在外企的时候其实是定时定量的。
我做的事情是组里分配的，做快做慢都是这么多，
组里的事情是部门分到每个 Manager 上的，
基本上也是合理分配相对固定的。
但是在互联网公司的工作是全凭主动性的。
不仅你做得快那么你要做的事情会更多（当然做的慢绩效就差），
而且很多事情都是可以砍掉的！
很可能大家一讨论，发现有更科学的方法去实现，整个东西都不用做了。

这样最直观的感受就是身边的同事 ownership 都巨高。
因为他做的事情是他参与思考讨论的，
所以大家的热情都非常高，
我第一次发现有这么多在家里都会工作的家伙…而他们居然都在我的公司里？？？

还有像新人培训。

QAD 有为期一个月多的新人培训，
期间除了业务培训，还有英文邮件、工作礼仪等等培训。
再惠技术部门的新人培训就只有一天，
一开始连 Mentor 机制也没，
就是靠招进来的都是大佬、大佬会自救自己想办法这么支撑下去的。
不过后来逐渐有 Buddy (就是Mentor) 机制，
以及有一系列完善的新手村任务熟悉业务了。

还有就是招聘。

在 QAD 招人的话我没参与过，
不清楚具体的情况，
不过基本上是 Manager 决定。
而我来再惠的第二周就让我跟着去面试了。
我很快发现相比于“挑选下属”的面试感觉，
再惠的面试其实是让我们“挑选队友”。
CEO/CTO 的最终面是质量把关，
前面的同事面试其实非常关键，
从不同角度去面试候选人才能保证永远招 A 类人。

当然，我们录用率只有 4% 这点也被 HRMM 们多次批评过，
不过反过来说，我们离职率也只有 0% 呀。

技术相关

虽然之前轻描淡写地讲了讲技术，
不过其实我在来再惠之前完全没接触过正规的 Python Web 后端开发。
我大概菜到一个什么程度呢？
就是假如津铭（上文提到的看起来事业有成的后端）当时面试的时候问我这些问题：
HTTP的请求方法每个有什么含义?/virtualenv是干什么的?/uwsgi是干什么的?
我一个都答不上来…

菜，得认。
所以我那阵子每天回家都跟女朋友说：
“我好菜啊，队友好强啊，
但我真的好开心啊，感觉啥都能学到，
而且他们下班也会写代码，
感觉找到同类了啊，不过感觉再也追不上他们了啊”

但我很快发现原本会绑住我的缚仙索不存在了：
我入职以后马上就有了各种测试环境的权限。
uwsgi配置搞不懂？那就去测试环境玩一下。
因为搞不懂而玩坏了？没事很快就会被前端爸爸找上门暴打一顿然后强制搞懂的。
恍惚间有一种刚玩dota时，选了个火枪然后很快懂了全英雄技能的感觉。

那阵子的周末我基本上也在写公司相关的代码。
因为周末不会有测试环境被搞挂或者是冲突的问题，
所以我可以放肆地试错，然后学到各种经验。

有了这段经验以后，
我十分确定一个事实：
尽可能地放权给程序员，
优秀的人会像李洛克解开了负重一样腾飞的。

生活相关

在再惠的工作内容其实我写了很多别的文章去讲，比如：
《我的工作》
《为什么我喜欢工程师文化》
就不过多阐述了。

换工作这个节点对我还有一层意义，
就是我跟女朋友合租了。

我爸妈都是老师，
小时候放学回家会听见他们聊各种学生、备课、科目组、考试的事情，
他们不仅生活上是温馨恩爱的夫妻，
工作上也会互相倾听给出建议，
这让我很是向往。
所以跟女朋友合租最让我开心的一点，
其实是下班回家以后可以瘫着，
要么听女朋友讲 HR 的职业生涯和各种破事，
要么跟女朋友讲工程师的发展规划和各种破事。

不过想了想，
关于女朋友我也专门写过《我的女友小米娅》，
感觉也没什么特别可以说的。

哎，高产的烦恼。

结尾语

坐在电脑前，
认真地想了一下毕业三年所做的各种各样的事情，
让我感受最深的并不是什么实在的事情，
而是我思想的进步。

对人友善、
用控制变量法研究问题、
换位思考这种从小就学的普适性的东西其实是非常正确并且有用的方法论。

希望这个世界会在你我的努力下，
越来越美好 :)

公司文化、工资期权、开发体验——一线程序员的喜怒哀乐

Sat, 11 Aug 2018 23:55:50 +0000

我有一群中学时学计算机奥赛的最好的朋友，
毕业以后我们散落在各个公司写码，
大家心照不宣地约定着“分开打钱，有事TP”，
时不时地就会聚在一起吃个饭。

Disclaimer:
本文内容涉及大量个人感想，
记忆内容有模糊，
一切内容真实性不保证，
有任何问题由作者本人背锅。（没错就是他，快喷）

（一）友情

Mia 有空的时候也会参加我们的季度聚会，
她和 YJ 的女朋友阿张是我们一堆男生聚会时的唯二妹子。
除了感慨：“程序员的手是好看啊。”
Mia 跟我也感慨过：
“我觉得你们这样真的很难得。
从初一初二就认识，
然后之后一直保持联系，
毕业以后也从事着一样的行业。
我觉得你们之间充满了共同话题。”
“对啊，日漫里面这就叫命运的羁绊。”

我们一帮队友里，
有毕业去了谷歌英国，如今已经找到真爱的队友；
也有毕业进华为，一直在出国的单身队友；
有一路深造还在读书的队友，
还有先后从微软、网易、依图跳入拼多多怀抱的队友们。

大部分时候我们会找个粤菜馆子吃点上海肠粉，
用来下饭的话题会从忍者村大战3v3经典对决，
聊到广东回南天和上海梅雨天的气候差别。
这次的聚会发起于刚从国外出差回来的华为小员工 enye。
就像以前的宿舍吹比一样，
这次的聊天吹比也让我颇有想法。

（二）公司文化

我们问 enye 他这次休息几天，
enye 说他请的三四天年假，可以休息九天。
众人：？？？啥操作？？？
enye 解释道华为有个约定，
就是出国回来默认有一天可以倒时差，
他就顺势请了一波连起来的假，以玩代休了。

enye 又讲到他其实有过想跳槽，
大家问起原因，
enye 感慨道：“我存不下钱啊。”
因为工作性质，enye 要走遍世界各个国家，
他又忍不住在知乎上关注了美食和旅行的话题，
也难怪存不住钱。

大家笑了一波他这第一世界的烦恼以后，
他又讲到：
“其实在我司，我难受的还有一种焦虑感。”
在 enye 的感受里，
华为是极度狼性文化的，
假如员工到了 35/40 的年纪还没有一定成就，
就会被淘汰掉。
enye 还举了个例子：
他认识的当时跟他同期进去的人，
现在已经全部受不了走人了，
而 enye 一直是 top performance 的，
他也感觉自己到 35/40 岁的时候不一定能做到高位。

听完以后我不禁感慨道：
华为毕竟是华为啊。
拼多多的早期员工 FM 也说道：
我们公司各种方面都非常想学华为。
我问 FM，你们拼多多也是狼性文化的么？
FM 点了点头，并举了个例子：
他们目前做的很多事情都是朝令夕改的，
比如对接京东、对接微信的组，
开发已经开发好了，
但是过两周，对不起，业务上合同没谈下来，
整个组都给我解散，
大家做的东西都白做了。
大家沉默了一会，感觉没什么能说的，
就念了念阿里的咒语：“拥抱变化，拥抱变化。”

我又接着问 FM：“那开发量上，你们忙吗？”
在两个组的 FM 和 Freedom 同时给出了不同的答案。
感觉很忙的 Freedom 说，
他们做的是公司的数据分析层 (hadoop + flink)。
公司人多了一倍的同时，他们组一个人没多，
每天忙的一笔。
FM 就附言说，像 Freedom 的组其实是特例，
拼多多大部分组已经慢下来了，
现在分工细了，花在沟通上的时间多了很多。
举个夸张的例子，以前一个组三天就能做完的东西，
现在可能两个组要做三周。

“那听起来有点划，
你们还是 996 周日加班么？”
“对啊！”
FM 又感慨道，其实感觉现在的工作量可以不 996 了。
比如他现在带的组包括实习生有 6 个人，
很多时候大家的活都不是饱和的。

讲到工作时间的问题又有个例子。
说拼多多上市的第二天他们开了员工大会，
两千多人在一个大会场里席地而坐，
老大们拿了张纸条出来，
说：“我们来回答一些大家关心的问题吧。”
然后读到：“我们现在人多位子挤，会不会搬新办公室？
我们会不会每两周多休息一天，引入单双休制度？
我们会不会每人发股票？”
台下的员工们非常兴奋，
每听到一个问题都热烈地鼓一次掌，
单双休的问题最是热烈。
然后老大们给出了素质三连：“不会，不会，不会。”
听完这个故事，在场众人又流下了沉默的无奈的泪水。

作为局外人的我叹了口气：
讲道理全中国我只听过你们这一家这个量级的公司，
是全公司 996 的，其它顶多是分团队或者短暂的。
感觉单双休这个问题，
只有你们老大黄铮发言，
真正官方给意见才行。
不过话又说回来，
你们招人的时候给的钱估计是按 996 给的，
现在换成 995 了，
除非你们愿意降薪 16.6%，
要不公司肯定是亏的。
Freedom 又补充道：
对啊，现在其实有很多组的人是自己固定请事假，
然后达到手动降薪单双休的效果。

大家又扯了一波单休和双休的本质区别，
总结出了一条真理，叫：
公司文化完全取决于老大，对小团队也是如此。
因为很多事情是只能由老大拍板的。

讲着讲着，我又想了想我司。
很多方面上，拼多多给我的即视感跟我司非常像，
要总结一句可以是：“当下中国快速发展的互联网创业公司大抵如此，很多制度难以跟上。”
但另一方面，我又觉得很多事情我司的操作性比拼多多要强。
拼多多发展的比我司快很多，
所以很多基建、文化很难同步赶上，
但我司首先是有双休，
然后文化上内部的宣传也比拼多多好些。
讲着讲着，Freedom 想起了他毕业后去网易的事情，
笑着补充了一句：“其实公司文化这个东西，
对刚毕业的应届生影响很大的。
很多人对职场一辈子的感知都起源于最初的印象。”

是啊，就像小王子感慨的那样：
沙漠的美，源于它之中隐藏的甘泉。

（三）工资期权

讲到拼多多上市的员工大会，
我又问了一个敏感话题下的不敏感问题：
“你们上市以后，期权兑换股权的方式是怎么样的？”
得到的回答是标准的美国科技公司的做法，
跟网上的说法是一样的。
比如拿硅谷里的 PiedPiper 公司举个虚假的栗子：

公司还没上市，是没有股票，只有期权的
- 理论上，等上市了，期权可以用来换成股票
- 但期权也不是免费的，需要用行权价购买
- 一般来说行权价比较低。举个栗子，相比于上市股票每股10USD，行权价可能是每股0.5USD。
PiedPiper 刚创业的时候发出了 20% 的期权。
- CEO 自己出的钱，出了 Idea，贡献了自己的住处，一个拥有 10%。
- 其它 5 个早期员工每人拥有 2%。
- 所有事情 CEO 拍板。
剩下的 80% 大家设立了为期 4 年的期限均摊。
- 这样即使第一年某个早期员工走了，他也只有 2% 的期权，不会占着茅坑不拉屎。
- 之后来的新人也是 4 年领完所有期权。
- 大家努力干活，一条心做好产品。
过了三个月，产品原型出了，算了一波市场以后，公司估值 80 万，投资人 A 投了 80 万。
- 本来公司估值是 40 万，期权已经分出去了 20%，投资人给两倍钱就是要 40% 的期权。
- 但是投资人说：这样，公司估值给你做翻倍，但是我想现在分完期权，等不及 4 年了。
- 公司缺钱投放产品，同意了。于是 CEO+众人拿了 80 万现金和 50% 的期权，投资人 A 拿了 50% 期权。
- 投资人 A 占得期权比高，不过公司还是 CEO 拍板，只不过每个月都要跟投资人 A 开一下例会，说一下拿着钱干什么去了。
产品投放以后，效果很好，一年后，公司招了人，估值 300 万，又从投资人 B 那融了 200 万现金。
- 因为之前期权分完了，所以现在新资金来了，大家的期权都被稀释了，大概比例是
  - CEO 15%，五个早期员工 3%，投资人 A 30%，投资人 B 40%。
- 现在 CEO 每个月要跟投资人 A 和投资人 B 开例会，有的时候要按投资人的想法来做事情。
随着公司的发展，引入了更多资金，甚至公司准备上市了。
- 多个投资人和专业经理人组成了董事会，大部分公司业务方向由董事会决定，CEO 成为了真正的首席执行官。
- 为了写清楚募股书，公司停止了对新同事的期权发放。
- 为了避免公司上市后现金流损失，董事会建议 PiedPiper 设定了一个为期 5 年的期权兑换时间。
- 因为后来发的很多是子公司的期权，所以董事会对不同子公司制定了从 5:1 到 10:1 不等的期权股票兑换比例。

（扯的例子有点长，而且都是个人猜想，可能很多不准确）
FM 主要讲了一点，
就是拼多多的期权兑换方式是 4 年拉满期权，兑换现金的时间还要 3 年。
这一听大家就都很蛋疼，
不约而同地说道：“那 FM 你这就肯定不能跳槽了啊，要不亏的一笔。”

为了量化这个亏有多少，
我们又猜想了一组虚假的数字：
假设有 100k 股期权，
每股行权价是 0.1 美元,
上市发行价是 20.5 美元,
期权股票兑换比例是 5:1，
期权交税比例是 40%，
期权发放时间和兑换时间都是 4 年；
那么公司上市成功了以后，
你可以换到的现金是 (100k / 5) * 20.5 - 100k * 0.1 = 400k (美元)
你本质上这 8 年的工作相当于每年年薪多了 400k / 8 = 50k (美元) 约等于 350k (人民币)。
也就是说跟着公司创业成功的你，
相当于每年多了 35 万人民币的年薪。

听起来很多，
那么我们再算下数学期望。
假设创业成功上市是九死一生的，
也就是概率是 10%（很高了！）
那么你在不知道公司未来的情况下，
创业公司的大饼 buff 其实等于 3.5 万的年薪，
约等于 3000 元的月薪。

一顿瞎比分析以后，
大家又总结了一波：
“大部分情况下，你能拿多少的数学期望是恒定的。
不论你在小厂、中厂还是大厂。”

不过讲到这里，
我不禁又跟 FM/Freedom 吐槽：
“你们拼多多实属异类，给的钱是真的多。”
之前金三银四的时候，
我们发 offer 的好几个人都直接去了拼多多，
一问为什么，offer 开的价格接近我们开的两倍，
真的夸张。

不过我司有个好处，
就是绝对保证公平，
比如我是觉得我们公司没有任何倒挂的情况。
（倒挂：指的是因为行情变化，导致实力差距较大的同学因为入职时间先后，导致薪酬反转的一种现象）
互联网行业因为很吃研发水平，
所以导致优秀人才的薪酬是在逐年上涨的，
市场涨幅比公司涨幅高的结果是很多情况下同是毕业入公司，
16 年毕业的工作一年的老同学比 17 年刚毕业的同学薪酬还低。
知乎上还有个很火爆的 600W 阅读的问题《为何公司宁愿给新人开高工资，却不愿意给知根知底的老员工涨薪？》就是讲这个的。

讲到倒挂，Freedom 就很痛苦地回忆道：
“我感觉当时我在的组，我的绩效是 271 里的 2，但是回报却是 1，很不公平。”
271 讲的是大部分公司激励制度是会按正态分布，
给表现最优秀的 20% 人最好的奖励，
让表现最差的 10% 吃屎（或者政治正确的说法叫给工作建议），
剩下的 70% 彼此彼此。
不同 Leader 的政策是不一样的：
有些 Leader 喜欢让大家轮流吃屎，
好处是大家和谐，
另外的 Leader 会让最差的吃屎，
很多情况下固定就是那个人一直在吃；
还有些 Leader 会有新手保护，
刚毕业的、刚加入团队的新同学最开始是不会吃屎的。
不过大家又吐槽，假如就按 dps 算的话，
新人是应该吃屎啊，我们也是在吃屎中成长的呀。

一边说着，新上的油条肠粉又被大家瓜分干净了。

（四）开发体验

讲钱相关的话题总有一种大人的感觉，
庸俗又真实。
为了让话题不这么沉重，
在思考职业发展的 enye 又问：
“不考虑钱的话，去早期公司、中期公司、大公司有什么异同吗？”
“不考虑钱的话，”我想了想，说道，
“我非常、非常喜欢优秀的小厂的工作环境。”

一方面是开发体验极好。
我们在只有几个人的时候，
虽然技术有分工、分前端和后端，
但是每个人都是业务全栈的，
也就是任何人能做任何事情，
数据流向数据存储数据格式？你的锅。
业务代码增删改查400/500？你的锅。
发版部署服务分布依赖关系？还是你的锅。
而且每次改动都是很快见效，
反馈效应极强。
FM 默默点头：
那个时候没什么沟通成本，
我说两天能做完，
然后两天就肝出来了，
你觉得我很牛逼，
我也觉得自己很牛逼啊！

另一方面，就像 FM 说的，
是沟通成本的问题。
我问 FM：“你有没有感觉你们人多了以后，扯皮非常严重”
FM 说有，并且举了一个具体的例子：
他们研发因为人很多，
很多人都彼此不认识，
所以并不知道谁是组长谁有拍板的权利。
然后业务问题很多都是模棱两可的，
时不时就有人对业务问题产生了分歧，
然后 argue 了很久也没能拍板，
导致很多时间都花在了沟通上。

讲到这个话题，
大家共鸣非常强，
工作既涉及开发又设计产品经理还涉及客户关系维护的 enye 非常激动地说：
“你知道为什么吗？这就是屁股决定脑袋！”
很多时候双方互相冲突的观点其实都是正确的，
问题是出在两个人的屁股都是朝着自己的方向的。
就算你到了高层也是一样，都是做着决策层的需求，
但是你们 KPI 不一样，团队也是不一样的，
自然就难避免扯皮了。

聊到这里，我又想起了 OKR 整套方法论里面很重要的一个概念叫“校准”。
就是说大的任务被拆分时，
第一要保证的是它们的方向一定得是一致的，
不能有互相冲突的地方。
方法论里都这么讲了，
那反过来说这个问题其实是广泛存在的。

讲着讲着，FM 就老气横秋地说道：
“所以其实作为研发，跟产品、运维、市场这些人搞好关系是很重要的。
即使是工作里，大家假如不作为伙伴互相看待的话，其实非常蛋疼的。”
众纷纷点头认可。

扯了这么多，
我发现偏离了一开始的主题，
就补充道：
其实小厂好还是大厂好，
我感觉是不仅看人，还看团队的，
我是非常喜欢目前的团队氛围。
举个栗子，
我们前携程队友，
他来了我司以后感慨：
“卧槽原来还有这样的地方啊，
我以前在大公司学到的扯皮的那么一套居然都用不上了！”
众笑。

（五）感情生活

几个上世纪出生的男生聚在一起，
就聊起了 PLMM 的话题。
大家发现在场的 5 人里有 4 人是单身的，
并且有小伙伴都进入了“还是琪亚娜比较可爱”的佛系状态里，
不仅唏嘘了一下。

最后，大家纷纷给下周一就又要去西班牙的 enye 头上插满了 flag:
“下次来上海，要带着妹子来。”

（完）

为什么我喜欢工程师文化

Thu, 26 Jul 2018 22:38:44 +0000

Mia 公司的母公司是 3G资本，
她前几天突然好奇公司的文化是怎么样的，
就去找了相关资料读了一遍。

然后 Mia 惊奇地跟我说：
“我发现 3G资本对人才的要求特别神奇。
三个关键词是 smart, poor, desire to be rich…”
空气中顿时充满了快活的笑声。

后来我又想，
我司有什么企业文化呢？
假如要我来说的话，
大概就是 工程师文化 吧。

工程师文化

看美剧的时候，
我们会发现美国人一楼总有一个车库，
车库的工具箱里装着各种各样祖传的实用工具，
Mickey/Rick/Baymax 都是从车库里走出来的。

软件工程师的工程师文化跟这个场景也很像：

在实践中学习
用工具解决问题
自主决策

我很喜欢这样的工程师文化。
具体来说，
我们举一个B轮公司的研发部门为例子，
也就是我目前在的公司：
再惠（上海）网络科技有限公司。

在实践中学习

我司有一份文档，
叫 the Hitchhiker's Guide to ZaiHui Dev，
俗称“新手村任务”，
这个文档大概长这样子：

文档里的章节包括搭建开发环境、
熟悉基础业务、参与合作流程、认识基础架构、
还有名为 DLC 的包括权限、队友、小脚本等附录。

除了这一套完善的文档以外，
每个人还配有一名 buddy，
就像老刺客带新刺客一样，
新同学在万物皆虚万事皆允的路上不管有任何问题，
都是可以抓着 buddy 问个透彻的。

比如其中后端的新手村任务大概长这样子（节选）：

玩 API
- 本地跑一个 server，尝试用接口获取 id=1 的商户信息
- 尝试用测试环境的登录接口，拿到自己的 key
- 想办法给所有测试环境添加自己的权限账号
- 通过调用 api 的方式修改自己库里的用户名
玩 DB
- 在测试环境入个会
- 在代码里找到“阿瓦达索命”相关功能，注销掉自己的账号
- 研究发验证码的代码 (pin.py) 到测试环境给自己设一个永久验证码
写 Bug
- 尝试搞挂<惠吧烤鱼>这个公众号，让微信提示“该公众号无法提供服务”（记得修！不然测试爸爸要叫！）
- 尝试不用 random 库，写一个有几率会挂的 ut
- 写一个循环引用，让所有 ut 都挂
- 尝试去测试环境改一下代码，然后搞坏该环境的发版（期待结果是在 pull_new_code 的时候报错）

一般来说，
有 python 经验的同学可以在一周左右做完新手村任务，
了解我们的主要业务和后端的大致实现框架。
刚毕业的同学也可以在整套流程中认识到 RESTful/MySQL/Git/Jenkins 等开发流程。

对应的，我们还践行 DevOps 的原则，
就是 Eat your own dog food。
不仅包括开发+架构设计+环境搭建一体化，
还包括可以瞎比玩别人的测试环境，
一个环境我搞挂了就得我来修，
不修的话就会被拿刀抵在背上来修（并不）…

用工具解决问题

截止到目前（2018年7月）为止，
我司技术部门（各端研发+测试）一共不到60人，
对应我们年费制的数千家商户，
平均下来每个人支持了100家商户。

这么想想敏俊（96年的刚毕业小帅哥）也支持了100家商户，
想想也为他感到有点小激动…

这里就是我们用的大量工具起到了杠杆的作用，
放大了每个工程师的生产力。

当时我被面试的时候，
谢老板的一句话给我印象很深：
“能用工具解决的问题，
我们是不会让工程师上的。”

具体来说，
我们看一个典型开发流程所要经历的一些步骤。

迭代

我司一直跑的是敏捷开发，
早期用的是 Trello。
那时不仅产品不多，
产品经理也不多。

后来队友逐渐在增加，
就尝试用了 Jira。
Jira 的好处是它功能强大可配置，
配套的 Confluence 等设施完善。
但是因为配置起来比较繁琐，
也没有让我们自己反复调整的时间，
大部分队友也就不太适应 Jira。

后来一直到现在我们在用 Teambition。
目前每个产品线有自己的敏捷面板，
每两周一次迭代，周一计划会，下周五回顾会。
每天早上晨会，大家除了过一下昨天的进度和今天的计划，
还会主要把一些小的疑问/困难放在晨会里说出来，
10 个人的晨会大概 10 分钟就结束了，效率巨高。

前几天面试的时候，
一个唯品会的小姑娘好奇地问我：
“你们的迭代是两周定时的么？”
我意识到其实不同团队对迭代的执行细节不一样，
就跟她解释了一下我们对迭代的理解：
“其实迭代就像地铁班车，
我们是写死两周一班车，
这个迭代能做完什么就做完什么。
车又不等人，做不完的下个迭代再做就行啦。”

VCS

我们用的版本控制工具是私有部署的 GitLab EE。
除了 Repository，
还用上了里面的 Merge Request/CI/CD/Docker Registry/Wiki 等功能。

比如举我们的机器人 KevinBot 为例，
假如想要给 Kevin 加一个新功能大概流程是这样的：

fork 项目到本地开发
push 到自己的 repo，提一个 merge request
触发了 CI 检查
- flake8 检查一波有没有语法问题，比如用了双引号、忘了写逗号
- django 检查一下有没有 migration 上的问题
- 跑完全部 ut，看看单元测试能不能过
跪求 code owner 来 review 自己的代码
- 会有线上评论，不好解释的会线下解释一波
- 有问题就打回去改了，重新 push
approve + merge
自动触发了 docker 的自动构建
构建完成以后自动触发了发版，kevin 机器人发版完成

整个过程中 contributor 需要 fork + coding + merge request，
code owner 需要 review + approve + merge，
剩下的单元测试、镜像构建、版本更新都是一条流水线做完的~

于是小机器人就更新了一个又一个并不实用的好玩功能

监控

我们的监控系统分为几块。
所有监控的告警我们用的是邮件 + 微信机器人。
机器状态的监控我们用了云平台的自带功能 AWS CloudWatch，
业务的状态、日志监控我们用了 ELK 整套系统，
还有最直接实用的错误监控我们用的是 Sentry。

比如说一年前每周都有好几个发版夜的时候，
大家都是一边看着 Jenkins console log，
一边看着 Sentry 看看会不会蹦出来一些 error log。
有的话当然就火线编程了！
（于是当时就有这样的九核围观的梗：

后来我们终于迎来了正规军测试小伙伴的加入，
Sentry 依然还是我们在测试环境用的一个非常有效的 debug 手段，
不论是 error 还是 warning，
Sentry 上的每一个错误都有几率被抓起来吊着锤。

有一次 Sentry 变慢了一些，
都被敏锐的旭总察觉到了事情并不简单，
从而牵扯出了一桩案件：《破案·Sentry迷云》

自主决策

上面讲的这些工程师文化的方方面面，
各个优秀的团队都绝对也一样有这样的工程师团队。
但唯有一点，
我是觉得只有我司是特别的。

套用一段之前在高德干活的拉总讲的话：
“我以前在高德，做的事情是领导分给我的。
我的领导呢，做的事情也是他的领导分给他的。
所有人要做的业务、要使用的技术都是相对固定的。
但是在再惠，根本就是怎么好怎么来。
而且实话说，我以前根本没有想象过，工作能这么开心！”

拉总总是这么睿智（棒读）。

政治老师说过，
我们答题要用总分总的形式容易得高分。

看来工程师文化令人喜欢的一个原因，
就是工程师们也十分令人喜欢呀。

（完）

最近跟女朋友的周常

Tue, 05 Jun 2018 00:22:48 +0000

最近因为加班有点多，
经常打断二人世界，
导致女朋友有点不开心。

（一）
前几个月的时候周常去觅食，
去的店家是港式风格装修的。
米娅正很开心地跟我讨论着墙纸上的 sasa 店面，
我眼角瞥见了桌上有一张二维码。

“哇你看，他们家也有微信点餐。
我这几个月加班都在做这个！
你等我下我拍照发群里，
看看人家做的跟我们做的体验相比如何…”

顿时米娅跟我聊天的兴致全无了。

上周末的时候，
吃饭过程中又接了个语音，
然后我跟米娅说，
吃完饭我下午要去公司。

米娅就很好奇地问了我一句：
“你们公司出 bug 都是你修吗？”

我安慰米娅说：
“有些别的同事也要周末修 bug 的啦。”

（二）

第二天晚上跟米娅吃完饭出去散步消食，
不知不觉又聊到了加班这个话题。
出于“爱一个人就想跟他分享全部”的道理，
我不禁又跟米娅喋喋不休我的工作起来。

“我跟你说，我感觉每个人的属性真的是不一样的。”

米娅捧哏：“嗯？”

“比如说我们公司吧。
因为工作制度是 965 + 弹性时间，
所以每个人的方差其实很大。
有些同事就是按时上班按时下班好好工作，
也有些同事跟我一样就是加班划水。”

“噢，也就是说你们真的有人是不加班的咯？”

“对啊当然。
你看加班这个属性，
其实不是跟公司绑定的而是跟我绑定的，
我在 QAD 不也晚上洗完澡回去干活么…”

“噢…”

（三）

不过讲到这个，
我又想起上次看到的一个很好玩的说法：
“离职爆破半径。”
于是我想办法用人话跟米娅 demo 了一下：

“虽然说每个人都是平等的，
但人和人之间真的差别还是蛮大的。”

“怎么讲？”

“比如说你看我们现在几十个人，
少几个人好像没啥问题。
但其实我拍脑袋可以数出几个人，
只要他们一瞬间全部离职，
我们的事情就会崩。”

“啊？为什么啊。”

“因为我们目前很多事情其实不是靠制度在维护的，
真的是靠优秀的人在顶着。
而且因为这些人太优秀了，
所以很多制度上的事情感觉还没有做的必要，
非常地‘以人为本’。”

（四）

“比如说我给你举个具体的例子，
就是 support。”

“嗯好~”

“我们公司是做 B 端产品的嘛，
也就是说商户其实才是我们的根本。
所以我个人非常信奉客户第一，
跟 QAD 讲的那个 Customer First 的 Core Value 是一样的道理。
不过像这句话，
我从来不会在同事的面前提。”

“啊，为啥？”

“因为我觉得这个问题很敏感。
比如说个具体的，
我们目前是没有 technical support 部门的，
也就是说有任何搞不定的技术问题，都得 R&D 上，去解决问题。”

“啊？你们 service 的同事呢？他们不是要负责上门安装么？”

“对，我司分工里这叫 Customer Success。
他们其实也蛮苦逼，要负责 service + support 的工作。
不过他们不懂技术，所以我刚才说我们是没有 technical support 的。”

“噢噢。”

“这个没什么好或者不好，
这个是我们目前的现状。
但是问题是我们招人的时候，
或者说公司战略上不会明确这么一件事情：
就是技术的工作职责里包括支持。
这个其实就很崩，
人的屁股不同就会决定思想的不一样，
所以这里很多东西是纯靠我们的责任感去维持。”

“那为什么你们公司不设 technical support 呢？”

“唔，这个我就说不上话了。
我猜这个是公司成长之路上的阵痛吧。”

（五）

米娅想起了上次看到优衣库招聘启事上写的：
“我们是一家信奉实力主义至上的公司”
不禁感慨道：“那有家庭的人估计不能在这样的公司里工作。”

“是啊，而且我们还有那种结了婚但是工作巨努力的同事…
简直可怕…”

米娅又想到了什么，问：
“对了，那旭总是单身？”

我：“大概……是吧……”

讲到此处，
我和米娅才发现已经不知不觉走到了日月光。
只见门口的公交车站广告牌处，
一个“大满足”的杨洋正在笑容满面地看着我们。

“走，原路返回，回家。”

（完）

我的一点强迫症

Mon, 07 May 2018 22:07:44 +0000

每个程序员都有他自己的强迫症。
一旦被戳中了，
就不禁心里暗暗会喊一声“舒服”。

正确使用空格

有研究显示，
打字的时候不喜欢在中文和英文之间加空格的人，
感情路都走得很辛苦，
有七成的比例会在 34 岁的时候跟自己不爱的人结婚，
而其余的三成最后只能把遗产留给自己的猫。
毕竟爱情跟书写都需要适时地留白。

vinta/pangu.js

现代社会的程序员总是要接触英文，
而很多时候我们会在中文中夹杂英文。

这种时候假如见到不留白的字我就会很难受：

错误：我今天带GF去吃了KFC的嫩牛五方。
正确：我今天带 GF 去吃了 KFC 的嫩牛五方。

正确使用全半角符号

当时在微信公众号的文档 JSON 样例数据里，
发现了全角双引号的我，
就像初中时回宿舍路上，
在马路中央见到了一直死老鼠的阿锋一样惊恐。

中文使用全角符号，
英文使用半角符号并留白，
连接处使用全角符号。

错误：你们搞信息竞赛(OI)的有句话叫"code is cheap，show me your boyfriend。"
正确：你们搞信息竞赛（OI）的有句话叫“code is cheap, show me your boyfriend.”

文本文件以换行符结尾

No newline at end of file 这句话就像是“你房间没锁门”一样令人惊悚。

不过专业地说，
在 POSIX 标准里行的定义是：

3.206 Line
A sequence of zero or more non-<newline> characters plus a terminating <newline> character.

使用正确的词描述事情

你们这样地热情，
但还是要提高自己的知识水平，
识得唔识得啊？

古人有一句话，
叫“学好的地得，走遍天下都不怕”。

这么想来，
那个苍蝇问的那句话还是颇有思想性的：
“假如当时我们把屎叫做饭会怎么样？”

如何带节奏

Fri, 13 Apr 2018 22:44:45 +0000

3月份我司周常分享轮到我的时候，
我讲了这个话题。
就像学好了“meta编程”就可以编的一手好程序，
我想着假如大家能掌握“meta分享”的技巧，
那日后我们的内部分享便会是盛宴不断了。

本文语气更贴近 presentation,
文学性会欠缺一些。

背景

今天的主题是“如何带节奏”，
我们也可以说“如何说服一个团体”，
或者叫“如何增加你的影响力”。

所以很显然，
这次我要讲的东西很虚，
基本上全部都是鸡汤。
关于鸡汤类的文章/分享，
有一句话，叫：

甲之砒霜，乙之蜜糖

这句话出处我没太找到，
大概就是评价杨玉环的。
说到杨贵妃，古典四大美人之一，
她对于皇帝来说就是蜜糖，
但是对于劳苦大众来说就是砒霜。
这句话你也可以管它叫“千人千面”、“萝卜青菜”、“哈姆雷特和林黛玉”，
意思都是一样的。

朝闻道，夕死可矣

这句话意思其实就等同于“纸上得来终觉浅”。
很多时候我们看文章、听分享得来的道理，
觉得蛮普通的。
等到真正践行的时候，
会发现这个道理的确科学啊。

回到这句话，
意思就是你今天早上听了这个分享，
到晚上你就会发出“すごい”的感慨。
（众人愣，后笑）

喜欢就会放肆，但爱就会克制

这句话出自韩寒的《后会无期》，
他前阵子发了条微博：

大概我今天讲的也会是这样的。

所谓“古来圣贤皆寂寞，惟有饮者留其名”。
虽然我觉得今天讲的是我的肺腑之言，
但大家也就选自己信的部分听就行了。

理论

好了，背景介绍完了。
我们来讲“如何带节奏”的理论。
光是理论很干涩啊，
我们来想一个例子：
你在玩一个网络游戏（比如山口山），
你加入了一个很强大的组织（比如全服第一的阴阳寮），
你想在里面的主力阵容里有一席之地，
甚至最后可以带团，
那你应该怎么做呢？

大概的大纲是下面的四步：

打入内部
建立人设
注意技巧
不忘初心

打入内部

首先世界上每个组织都有自己一套的行为方式，
比如开源项目有自己的代码风格，
每个公司有自己的文化，
一个公会也可能有自己的副本时间表。
所以第一步就是：要多观察。
这里有一句话，叫：

新潜三

也就是“萌新要首先潜水三个月”的意思。

潜水三个月并不是说你这几个月不说话，
而是你在适当参与互动的前提下，
你可以有比较多的时间注意下像
“组织有什么黑话？”
“组织里哪个人是可以开玩笑的？”
“哪种说话方式可以让大家最舒服？”
“大家是以冲排名为目标，还是以休闲为目标？”

讲到这里还能引出一个问题，叫：

如何跟青少年沟通？

我从之前到现在一直觉得这很扯：
只要多跟他们聊天，
跟他们玩一样的游戏，
跟他们上一样的网站，
自然就知道“现在的年轻人”在想什么。
很多人既不想跟小孩子玩到一起，
又想跟小孩子有共同语言，
这肯定是不科学的。
比如后面我们要讲到的局座、葛平等人，
就是这点做的非常棒的。

不拉踩

这个就是字面意思，
任何时候我们做人，
不能“拉一踩一”。

比如玩游戏，
一个团里可能会有固定队伍，
我们一定不能说因为我们想顶替掉现在的T，
就只跟奶搞好关系，说“那个T怎么怎么样”。
这样为了短期回报，
而丢掉长期发展的操作是很伤的。
我们要带的是长远的节奏，不在一朝一夕。

早期A/B站的故事

这点俊儒也是A岛丧尸所以可能知道的清楚一些，
你们大部分人应该只知道B站很好。
不过其实当初B站创立的时候有一波不太和谐的操作，
具体的情况我也不能断定，
不过在我眼里就是有“拉自己踩隔壁”的嫌疑。
（不过运营、资本、大小姐什么的就是后话了）

不KY

KY 这个词，源自日语的“空気を読めない”，
翻译过来就是“不会读空气”。
比如举个例子，
我们公司玩 dota2 的人挺多的，
假如大家正在兴冲冲地讨论新出的英雄，
然后我说一句：“只有我觉得 dota1 比 dota2 好玩么？”
这就是 KY。
就算我内心真是这么想的，
但我也得在合适的空气（气氛）中说出来。

杠精

前阵子有这么一个词，
指的是那些“喜欢抬杠到成了精”的人。
比如我今天发了一条朋友圈，
说“哇我用 python flask 写了个小服务器好开心”，
然后评论就说：“为什么不用 java? java 效率更高”。
或者微博上的 @新垣结衣新闻社又发了 gakki 的九宫美图，
粉丝们都在舔屏幕的时候，
有人在下面评论：“就我觉得新垣结衣不是很漂亮吗？”

这样的事情不仅会破坏气氛，
还会减你自己的群地位。
尽量忍住别做这样的事情。

不冲突

字面意思，别跟别人怼起来就行了。

不过讲道理这条其实有点难，
我见过不少组织因为核心成员怼起来就散了的。

Game

分享到这里，
组织了一波现场小游戏：
每个人都讲一句 KY 的话，其他人来点评够不够 KY

因为在场的都是平常互黑的研发同事，
所以场面异常火爆。
（场面火爆++）

建立人设

下面的一些话写的有点中二，多见谅啊。

我说的人设这个词，
对应到英文可以是 stereotype
也就是“刻板印象”。
可能这个词词义本身是带贬义的，
不过我们要知道这是事实就存在的一种设定。

比如我刚来公司的时候，
跟大家没有共同经历，
所以你们认识我肯定就是从我的一些人设开始的：
交大毕业的、柳老板的室友、广东人。
所以我黑一下复旦，黑一下柳老板，黑一下福建人都是非常“符合人设”的举动。

这里首先要说到的第一个人性的弱点就是：

凡人皆愿掌控世界

比如前阵子我搬家，
我发现人类有一点是很好玩的（用轻蔑的语气说的，众笑）。
就是很多人没有活在真实的世界里，
我觉得他们仅仅活在自己的三观里。
比如我搬家的时候会接触不少的人，
每个人都会问一个问题，
叫：“你这房子借的多少钱？”
（提问：为什么是“借”？答：上海人好像是这么说的）
我每次都会说：“一般价格啦。”
注意这里我并没有直接回答他们的问题，
然后有些人就会说：“哦，三四千吧。”
也有些人会说：“五六千要的。”
这里他们的问题其实并不是想要一个真实的回答，
他们只是想用各种各样的方式加强自己的信心：
“嗯，如我所想。”

凡人总是想掌握世界运行的规律，
愚蠢的人类啊喵。（众笑）

不过这里虽然我们说凡人怎么怎么样，
但其实我们也是凡人。
假如不自知的话，
我们也容易陷入到这样的弱点里，
你去了解的不是事情的事实，
而是一直在加强心中的那个设定。
（比如有些面试官只凭第一印象去决定面试结果）

所以这里有个很重要的：

空杯心态

比如张总（正在认真听的张总一惊），
经过 GitHub 统计他是全国 Python 第一的程序员（众笑），
他不仅代码厉害，别人夸他的时候他还膜回去，
这就是典型的空杯心态。（众笑，张总：不敢当不敢当）

这种空杯心态不难达成，但是反过来就不一定了。
比如我苏子岳，讲真大学时候没学过《计算机网络》，
来我司面试的时候真的是连 Get/Post 的区别都分不清，
假如当时拿这个来面我，我肯定会挂。
所以假如当时别人说我“哎呀，你网络基础不行”的时候，
我不控制自己的话就很容易生气：
因为我的确网络基础不行啊！

所以不仅要在满了的时候保持空杯心态，
你杯子是空的时候更要意识到这个事实，
保持空杯心态。

吾等只知千人千面

上一节讲的是凡人，
这一节讲的是我们。
恕我直言，
在座的各位都是……
精英！（众笑）

听到这种好话，
我们肯定很开心，
不过稍一思索我们就会知道：
我们没有什么不同，我们就是凡人。

这就是一个人设里面很 trick 的东西：
语言里经常会说“我们怎么怎么样”，
但其实我是我，你是你，两个人是截然不同的人。

作为一个集体，
可能是普通的，
但只要细颗粒地去看，
每个人都是截然不同的人设，
每个人的形象都是不一样的。

环顾周围已经如此

上一节讲得有点虚了，
我们来看一下周围，
或者说大家都认识的人里有哪些是有“典型人设”的人吧。

高晓松

一方面，我在公众场合发言，
讲道理我应该注意观点理中客。
不过另一方面，我讲话只代表我个人的想法。

我觉得高晓松某些程度上跟罗振宇是很像的，
两个人都是因为一定的特质受部分人群的喜欢，
但其实我们要知道他们被喜欢的是人设。
比如知乎上会有“高晓松讲的东西不对啦，
罗振宇的60s语音是提前录好的啦”之类的讨论，
大部分时候这种事情都不会影响他们的公众人设。

葛平

（此处给不懂葛平老师的人放了一下原版，
经典作《循环》，
还有葛平老师自己唱的循环）

跟局座一样，
葛平也是在年过半百的时候突然被安上了“奇怪的”人设。
但是他们都非常开心地接受了自己的人设，
并且有的时候还会大方地拿自己的人设开玩笑。
很多年轻人一开始只是想恶搞一下他们，
结果最后却真的被他们的人格魅力所吸粉了。

自然反复迟早身陷

讲这么一长串，
我想表达的内容就是“人设”这个现象是自然存在的。
只要利用好人设这一点，
就可以迷惑大部分的凡人。

那怎么建立这点人设呢？
比如会有个老梗说雷锋把好事都写到日记里。
从我的角度来看，
假如一个人假如能360度地维持人设一辈子，
那他就是这样的人。

对于大部分普通人，
他的人设是什么样，
基本上就是取决于他这个人本来就是什么样。

当你凝视深渊的时候，
深渊也在凝视着你。
你无法抵抗。

Game

讲完了人设这么一节，
在场的各位又玩了一次游戏，
叫“每个人讲三个自己的人设。”

这个环节也是非常火爆，
通常是一个人没讲自己的人设，
大家都争先恐后地帮他回答了。

不过中间发生了一件蛮好玩的事情，
拉总讲到自己一个人设是“内向”（众笑）
后来拉总跟我聊天的时候，
聊到动情处，
拉总说他自己其实对陌生人是不会很热情的，
很多人觉得他很外向，
但其实他觉得自己在这环节里讲的“内向”才是他的性格。
我不禁陷入了思考。

这样的游戏环节蛮好的，
不仅能侧面佐证一下分享内容，
还能引起了真真切切的思考，
十分科学。

注意技巧

下一章主题叫“注意技巧”。
现在我们打入内部，有了自己的人设，
面临的就是各种各样具体的事情了。
我们接下来来看一些具体的“术”，
这一部分实操性比较强。

比如一个小栗子就是我在讲的时候啊，
汤总听得都很认真，
他一边听还一边默默地点头表示认可。（众笑）
有个说法是在会议室里，
一个人默默点头是可以增加群体的认同感的，
俗称就可以叫“托”。
汤总：我不是，我没有，别瞎说啊！（众笑）

逻辑

说回正题。
从我的角度来看，
跟别人沟通中讲逻辑是很重要的。
我这个人并不要求别人讲逻辑，
但我一定要讲逻辑，
逻辑清晰的话比较容易把事情说清楚，
各种意义上都会减少误会。
比如说：

知之为知之

这点其实是很平常的道理，
但大家可以观察到很多人是做不到的。
这点跟上面的空杯心态有一定重合，
就不讲了。
跟大家讲一个实用的小技巧。

FFC (Fact, Feeling, Compare)

人性的弱点之一是：
人被表扬就会开心。
所以我们想影响一个人，
很好的一个切入点就是去表扬他。
这个 FFC 原则，
就是我们表扬别人时可以具体用到的原则。

比如说今天女朋友给我做了一餐饭，
我可以这么去说：
“今天的罗宋汤颜色好鲜艳，闻起来很香！
（这是 Fact, 事实）
光是看我都看饿了，我觉得你做饭超厉害的！
（这是 Feeling, 感受）
以前我都不会主动吃番茄的，只有你做的我才喜欢吃！
（这是 Compare, 对比）”
这么讲完以后，
女朋友会很开心，
然后明天我也能喝到她给我做的汤了（众笑）

这个原则很好记，
等下的游戏环节我们就会玩“用 FFC 表扬一个队友”，
大家可以想想。
一般来说，
关于表扬别人还有一个说法，
叫：

表扬要公开表扬，
批评最好私下批评。

很简单，
我今天跟张总一个人说“你是全中国 Python 第一的程序员”（众笑）
张总就是单份的开心。
但我今天在大家面前说“张总是全中国 Python 第一的程序员”
在场有 N 个人，
张总就会获得 N 份快感（众笑）
超捧场的张总：我好有快感啊（众狂笑）

逆向

刚才我们讲的是正面的东西。
有的时候一样东西反过来看又是别样的风景。
比如我很喜欢的一个作家叫“蔡智恒”，
他网名叫“痞子蔡”，
就是写《第一次的亲密接触》的那个人。
他一本书里讲到过这么一个故事：

右边的石头

就说一个旅人在爬山，
一路上很累，但风景也很好。
走啊走啊他来到了一个岔路口，
路的左边是一条一眼望得到底的平坦的路，
路的右边是一块很难爬上去的石头。
他这时候想了，
我是走左边的、风景平常的山路，
还是试着去爬爬右边的石头呢？
最后他选择了走平坦的路。
但他一路上都忍不住想：
“假如我当初爬过了右边的石头，
又会是什么样的风景呢？”

这个套路其实就叫“心结”
很多影视剧/动漫里面都会用，
比如男主小时候有一件blabla的什么事情，
影响了他的一辈子。

这点对于推进波澜曲折的剧情是很棒啦。
但我觉得作为活着的一个人，
根本不要去在意什么右边的石头，
既然选择了左边的路，
就一条路走到黑。

（讲到这里，突然觉得不知道怎么讲下去了）
呃，我们的分享主题好像是“如何带节奏”对吧，
咋就被我讲到了个人三观了捏？（众笑）
不管了，我 PPT 都写好了，继续讲。

半满杯子

这个故事你们大概听过。
就是一个装了一半水的杯子，
乐观主义者看了觉得还有一半水呢，
悲观主义者看了觉得只剩一半水了，
工程师看了觉得这杯子容积是额定大小的两倍。

这个经典故事说明的道理也很简单：
看问题的角度会改变问题。
我们不会说“当乐观主义者是对的”或者“不能当悲观主义者”，
假如我们想能站在更高的位置去看事情、做事情，
我们就得能在不同的角度去观察一件事情。

站在人群中

这个用西方的一套说，
可能叫“众生平等”。
不过从我的角度来说，
就是我们平常思考问题，
一定一定不能把人分贵贱，
把人分三六九等。
因为这会阻碍我们换位思考，
让我们“逆向”的思考只会在我们“平级”之间流转。

比如靖哥哥，我觉得他牛逼，
他讲的我信，我只想跟他交流问题。
但强哥是产品转来的，
我觉得他是个菜逼，他说啥我都不信。（众笑）
例子可能有点夸张了，
但这样你们一听就会觉得不妥，
对吧。

苏轼有一句话，
叫“吾上可陪玉皇大帝，下可以陪卑田院乞儿（，眼前见天下无一个不好人）”
这句话我就很喜欢。

空杯

又讲到空杯了，
这里可以讲一个故事

苏格拉底

这个故事比较经典，
大意是说有人问神谕：
“全雅典最聪明的人是谁啊？”
神谕说是苏格拉底。
苏格拉底听到了这句话以后大吃一惊，
他说：“不对啊，我觉得我非常无知。”
最后他发现，
正是他清楚自己的无知，
这一点比很多人都要厉害。

对应自己的弱点，
还有一种我们经常会遇到的情况是人生的逆境。
这里有个词，叫“逆商”。
所谓智商、情商、逆商，
智商是怎么处理逻辑问题，
情商是怎么处理人际问题，
逆商大概就是怎么面对逆境了。

我们人类没办法在瞬间改变环境，
所以很多时候面临逆境，
本质上就是处理我们跟自己的关系。
湖南人有一句话说得好，
叫“霸得蛮，耐得烦”，
大概就是“坚韧不拔”的意思吧。

满谦

空杯还有一点，
就是满谦……
（写文章跟分享的时候差了几周，
所以本来好像这里才是将上面的例子的…
不过这并不重要了，过。）

不忘初心

收一下，
我们讲了这么多关于“如何带节奏”的东西，
假如你回去试着去用的话，
你会发现一点：
“最开始你能带节奏的人，都是你身边的人。”

举个例子，比如何总2016年写过一篇博客，
里面有一句话，叫“2017年要监督女朋友培养正确价值观”，
这就说明他是很能带他女朋友节奏的。

除了伴侣之间，父母子女之间也很容易带节奏。
再举个例子，我经常会跟女朋友一起看各种访谈之类的，
有的时候里面的人就会说：
“我现在怎么怎么样，
是因为小时候我父母怎么怎么样，
给我造成了永久的伤害。”

所以假如你有带节奏的能力，
你一定要记住两句话：

别忘了你要带什么节奏
别忘了你自己是什么样的人

比如回到最开始，
我们在玩网络游戏，
我们加入了一个很强大的组织，
我们的目的是什么？
没错，我们的目的是想在团里排进主力阵容，
甚至是当团长。

这就是我们最开始的“初心”。

实践

道理讲了很多，
剩下的都是实际去试了。

The Zen of Python 里有一句话，
最后送给大家：

> Now is better than never.
>
> --- The Zen of Python, by Tim Peters

（完）

本文 slides 地址为 liriansu.com/slides/influence

所有内容为各种杂谈经作者二次消化完成

破案·Sentry迷云

Thu, 22 Mar 2018 20:14:08 +0000

作为程序员，
日常开发中经常会出现一些“不科学”的事情，
这种时候也是“破案”的好时机：
让我们来用科学，解释不科学。

起

又是平凡的一天，
坐成一排的程序员们正在噼里啪啦地写代码。
不知不觉间 deadline 逼近了，
想到这点，
大家不禁紧张地噼里啪啦地写代码。

突然，旭总眉头一皱，发现事情并不简单：
“我总感觉这几天 Sentry 的响应速度变慢了。”

Sentry, 英文单词直译是哨兵（漫威宇宙里最强者之一）。
也是一个非常好用的异常监控/收集/管理软件，
官网可以参见 sentry.io

我司用 Sentry 做了各端的错误收集，
大家养成了一出错先看 Sentry 堆栈分锅的习惯。

于是紫月就例行公事地看了一眼 Sentry Stats,
紫月觉得事情很简单：
“拉总你看看你的推送啊！”

拉总，绰号来源于 ID: lxkaka.
因为跟我们支付供应商拉卡拉 (lakala) 巨像而得名。

拉总在我司做后端，
负责过会员数据、平台监控、推送系统的实现。

跑过来看着紫月屏幕里 Sentry Stats 的数据，
拉总感到一脸懵逼：
“不应该啊，推送系统怎么能报这么多错呢？”

承

回到座位的拉总研究了一会儿，
惊呼道：
“我们是不是换过测试环境的 MongoDB 地址啊？”

旭总一脸鄙视：
“没换，要换也是两个月以前换的。”

紫月笑着调戏拉总：
“不会你的代码跪了两个月才发现吧？”

拉总赶快说：
“不可能不可能，我再看看。”

过了十分钟，
拉总二脸懵逼地站起来了，
十分迷惑地 Pub 了一句：
“这不科学啊，测试环境是好的啊。”

于是大家凑在一起，
整理出了目前几个已知事实：

Sentry 不停地在接受测试环境的推送系统 (zaihui-push) 的报错。
报错内容是 MongoDB 访问地址不对。
两个月以前我们换过测试环境的 MongoDB 。
但是代码级别上，测试环境用的 MongoDB 配置是正确的。

也就是说：
我们以为我们代码是正确的，
但是监控观察到代码一直在报错！

这很 (bu) 神 (ke) 奇 (xue) 。

于是我们决定破案一下。

首先，拉总检查了一下测试环境的正确性。
拉总把推送系统的 docker 都关了，
但 Sentry 还是一直收到报错，
这说明报错源不是测试环境。

俊儒指出 Sentry 说不定可以看到源 IP，
于是紫月尝试观测了一下，
IP 是没观测到，但是观测到了 Server Name。

ea064a694da5 这个12位的16进制数字是典型的 Docker Container ID ！

所以大家马上想到了暴力的破解方法：
把内网的所有 Docker Container ID 都找出来。

我司的测试/生产环境都在内网环境中，
只能通过入口机器 (gateway) ssh 到机器上。
为了方便运维，
内网机器都在 ssh config 里配上了名称。

于是紫月在入口机上执行了一段 bash 脚本，
把所有内网上的 Docker Container ID 都找了出来：

cat ~/.ssh/config | grep -G '^Host' | cut -d' ' -f2 | xargs -I{} ssh {} "docker ps" >> dockers_container.log

命令跑完以后，
我们打开输出文件，
激动地发现：
报错源不在内网里！

转

一下子事情僵住了，
大家的头绪离散到了好几个方面：

能不能模拟 MongoDB 的地址，然后抓包请求？
能不能在 Sentry 信息中翻到 IP 地址？
能不能通过 Docker Container ID 找到对应的机器？

经过思考以后，
大家总结出破案的关键在于整个网络调用：
我们只要捋一遍服务器的网络关系、调用路径，
就可以找到破案点！

问题一下子就定位到了内部系统的 Load Balancer 上。

我司隔离了生产环境和内部系统（比如 GitLab/Sentry 等）
类似于生产环境的入口机器 (gateway)
我们内部系统的流量入口也是我们用 nginx 自己搭的。

于是我们登上了内部系统的 nginx,
找到了 nginx access log,
整个文件大概有10万行。

...
42141 59.78.3.25 - - [22/Mar/2018:22:09:07 +0800] "POST /api/450/store/ HTTP/1.1" 200 41 "-" "raven-python/6.3.0" "-"
42142 59.78.3.20 - - [22/Mar/2018:22:09:07 +0800] "POST /api/355/store/?sentry_version=7&sentry_client=raven-js%2F3.22.3& HTTP/1.1" 200 41 "Mozilla/5.0 (Linux; Android 8.0; DUK-AL20 Build/HUAWEIDUK-AL20; wv) Mobile Safari/537.36 MicroMessenger/6.6.5.1280" "-"
42143 59.78.3.24 - - [22/Mar/2018:09:33:08 +0800] "POST /api/452/store/ HTTP/1.1" 400 62 "-" "SharpRaven/2.2.0.0" "-"
...

问题又来了：
要怎么在这数万行形态各异的 log 中，
找到哪一条是推送系统的报错，
从而找到报错源的 IP 呢？

可以通过 Sentry Endpoint,
也可以通过 Raven 的版本。
比如上述 log 中的三条信息，
分别是 Python/JavaScript/C# 向 Sentry 发送的错误信息。

推送系统用的包是 [raven==6.3.0][ravern],
于是我们就从中晒出来了真正的 IP：
59.78.3.25 ！
（本条 IP 已打码）

大家兴奋地都站了起来。
因为不是自己推送系统环境没配对之类的锅，
拉总也如释重负/火上浇油地喊道：
“破案了破案了！快看看这个IP是谁的！”

合

上网定位了一下，
发现这个 IP 是上海市的，
俊儒怀疑道：
“这怕不是就是我司办公室的流量出口？”

于是我们查了一下我们现在的出口 IP：

> curl -s httpbin.org/ip
{
"origin": "59.78.3.25"
}

顿时空气有点寂静，
因为目前的事实是这样的：

拉总确认过他开发的推送系统没有报错。
大家追溯下来，报错源就在我们办公室。
报错源藏在某个人电脑的 docker 里面。

那么问题来了：
究竟哪个人会 clone 推送系统的代码，
并且在自己的电脑上用 docker 跑起来呢？
那就只可能是开发者拉总本人。

大家围到了紧张的拉总的身后，
看着他敲下了 docker ps 命令：

> docker ps
CONTAINER ID IMAGE ...
ea064a694da5 zaihui-push ...

破案了！

拉总想了想，猜测说：
他大概是几天前本机调试了一下推送，
忘了关了。

那么真的如他所说是几天前吗？
大家打开了 Sentry：

数据无情地还原了真相：
两个月以前就开始报错了，
也就是按旭总的记忆，
从我们换了测试环境的 MongoDB 开始。

看着最后原来是拉总自己电脑搞的乌龙，
大家也是爆笑了一圈，
旭总顺带还调侃拉总：
“你的 Mac 电脑也是牛逼啊，开着几个 docker 都不卡的。”

后来看着 Sentry 的错误频率图，
大家又疯狂地笑了一圈拉总：
“拉总，这个 Sentry 报错早十晚八，做五休二，
可真能反映你的上班时间~”

事情的最后，
紫月从柳总桌子上翻出了门把手的“拉”和“推”两个字，
放在了拉总的桌子上：
“拉总，好吧，经此一役，
你也是我们的推总了。”

（完）

链家小哥问我：听说搞IT的培训三个月就可以月入上万，是真的吗？

Mon, 12 Mar 2018 23:22:10 +0000

我想了想，
说：
是的。

（一）

前几天跟女朋友去租房子，
因为我们一对情侣租的是两居室，
链家小哥自然就问一居室的考不考虑。

本着知道业务需求，
才能实现的更好的原则，
我就跟他说了下我是程序员，
有的时候晚上想工作到比较晚，
作息上会跟女朋友错开，
所以会住两居室的原因。

小哥听说我是程序员以后很好奇，
问：“你们程序员是干什么的啊？”

我想了想，跟他说：
“比如你们上传房间照片用的网站，
就是你们程序员开发的。
比如你手机上的App时不时要更新，
这些也是程序员做的。
比如微信、王者荣耀、或者说你手机系统，
都是程序员做的。”

小哥更好奇了：
“那你们这算是搞IT的咯。
我听我朋友说，
你们搞IT的，
培训三个月，
就可以找到月收入一万的工作，
是真的吗？”

（二）

小哥看我一脸懵逼的样子，
他就跟我说：
“年后我接待的客户全部都是搞IT的。
前阵子有个湖南那边的应届生来上海，
两个人租了九千块钱的房子。
刚过完年的时候，
也是有一对情侣，
男的比女的大不少，
也是搞IT的，
两个人也是租了七、八千。
前阵子还有一个客户，
一个人租了五千，
刚租了一个月，
（押金都不要了）
就去了杭州阿里巴巴那边上班…”

我：“呃。。。”
=_=

我想了想，
看小哥这么好奇的样子，
也出于我跟小哥交换行业知识，
小哥说不定也会跟我说怎么租房子便宜的私心，
我认真地解释道：
“你说的，培训三个月，
月入上万是肯定有几率存在的情况。

我们这行可能会被叫做“搞IT的”，
这其实是一个很大的职业范围，
这里会有各种各样的情况。

比如可能是有些有钱的企业在搞信息化，
这样的企业缺乏的不是技术上多么专业的人才，
而是各方面都很优秀的人。
有可能你本来跟人沟通啊、合作意识啊、业务能力啊都很不错，
然后你去认真参加了一个培训，
你获得了“搞IT”这项技能，
就像参加了英语培训、参加了挖掘机培训一个道理。”

小哥想了想，
他说是这样的。

（三）

小哥说链家正在改革，
所有人都是无底薪，
单纯靠提成维持生活。

“你知道吗，
我16年刚来上海的时候，
只要穿个西装打个领带，
站在街上就会有人问我买房…”
小哥怀念当年的情景，说道：
“我们很多同事，
高中没毕业，
08年、10年就做这行了。
早就在老家买房买车，
现在也在店里干活。”

对口相声讲究一人逗一人捧，
于是我感慨道：“这么厉害的吗。”

小哥也感慨道：
“是啊。
不过我们现在每天晚上都睡不着觉，
每天一起来就只有出账，
没有入账，
你懂这种感觉吗？
我就想了解下互联网行业怎么样，
有机会的话回老家做。
现在什么最火？
就是互联网。
现在这个时代就是互联网加的时代。”

我被小哥振聋发聩、洞悉行业、实事求是的发言折服了，
不知道说啥能接上话题。

（四）

不知道说啥的时候就切回主题。
主题是啥？
主题是培训。
好，那我们继续跟小哥说培训的话题。

知道了小哥其实有点认真考虑培训的话题，
我想了想，
给他又讲了下我知道的内容：

“唔，我把我知道的都跟你说说吧，
不过因为我自己不是做培训的，
所以我说的可能都不对。

首先，认真参加IT培训肯定是能找到工作的。
就像你说的，现在是‘互联网+’的时代，
这个社会对IT人才的缺口很大，
比如刚才看到的电子锁，
比如这两年出现的共享单车，
比如人人都在用的移动支付，
这里都是自动化，都需要工程师。

其次，找到什么样的工作不一定。
因为‘搞IT的’做的事情其实很广。
这个我具体阐述不来，
但你要知道很多时候‘搞IT’面对的是机器，
是传统意义上很枯燥的工作。
不适应的话，很多人都会干的很痛苦。

最后，培训本身来说，效果是因人而异的。
有些人可能培训了几个月，
他就学到了很多，
打开了一扇门。
但有些人可能培训了几个月，
他唯一学到的，
就是自己不适合‘搞IT’。

所以说，因为不了解你的具体情况，
这件事情我没办法给你具体的帮助。”

小哥听完以后，
陷入了信息量带来的卡顿中。
我又想了想，
给了个实操上的建议：

“讲道理你想了解这方面的东西的话，
我建议是这样的。
你问问看你老家那边，
或者有没有认识的亲近的IT朋友，
他们肯定更了解你、更了解你老家的具体情况，
他们给的建议，
肯定更能执行下来。
”

（五）

跟链家小哥聊了一路以后，
我回家也不禁一屁股陷进了“行业选择”这个话题里。

我想我自己选择行业的那一时刻，
发生在我爸给我填志愿的那一刻。

当时高三保送生考试去考清华，
考前要填三个志愿专业。
填志愿的时候特开心，
就像已经考上了一样。
当时很喜欢看讲建筑的《筑梦天下》和讲汽车的《Top Gear》，
清华的一二三志愿填的就是建筑学、土木工程、汽车工程。

后来考华约，我懒得又填一遍交大的志愿，
就让我爸帮我代劳。
我爸看了看表格，跟我说：“交大可以填五个志愿诶。”
应该是正在玩游戏的我说：“你看着填就行了。”
于是我爸对应的就给我填了建筑、土木、汽车工程、计算机科学、软件工程。
我看了看五个志愿，跟我爸说：
“我感觉中学已经写了六年程序了，
我以后大概不会想写程序的。”
就把第四志愿的计算机科学换成了英语系。

结果后来交大分专业的老师，
可能看我是学OI的，
就直接给我分到了第五志愿：软件工程了。
到今天我一直很感谢这位老师没有纵容我的小任性。

有的时候我会跟队友感慨：
其实科班生的几年学习，
最大的作用是让你知道自己喜不喜欢这个行业。
幸运的同学就会明确这一点，
并且在自己大学的行业上一直做下去；
也有的同学学完四年，
就知道自己并不喜欢这个专业/行业，
就会立刻转行。

就像链家小哥问的那样：

“听说搞IT的培训三个月就月入上万，
是真的吗？”

假如再问我一次，我会跟他说：

“可以是真的。”

假如再要我多说一句的话，我会说：

“只要你坚持在你喜欢的行业工作下去，
你可能会遇到困难、遭受挫折，
但你终有一天会因为自己的勤奋、勇敢而获得更好的生活。”

希望小哥能找到他喜欢的事业，
并且为之奉献一生。

（完）

我的好友柳宁宁

Sat, 03 Mar 2018 20:39:48 +0000

柳宁宁真名其实不叫柳宁宁，
我帮他解释真名都是某个朝代的某个职位。
但柳宁宁的快递名都叫“柳宁宁”，
以致于我的快递名叫“柳宁宁的同桌”。

柳宁宁和我是大学室友，
后来是工作伙伴。
因为在我司互膜文化盛行，
基本上互称不是X总X神就是X老板，
所以后来我称呼柳宁宁都是叫柳总。
硬生生地把大学几年的称呼都扭过来了，
现在我叫柳总真名反而不太适应。

柳总真名不叫柳宁宁。
不过他很喜欢柳这个姓，
于是有时需要录测试数据，
他不是录“蜜汁服务员柳宁宁”，
就是录“柳纯”。

柳总对隐私安全很重视。
柳总有一段时间把他所有不玩的账号都注销掉了，
但是有些网站没有提供注销功能（比如新浪微博），
他就很烦。
之前我在知乎上写文章经常会提到柳总的真名，
他的队友发现以后就吐槽了一波柳总，
于是柳总就拜托我把文章里的真名换成了化名。
我有些换成了柳宁宁，
有些换成了柳纯，
有些换成了ldsink。
后来柳总盯着搜索出来的五六篇文章，
感慨道：“这么多文章，简直像是女朋友…”

柳总的ID是ldsink。
GitHub/ldsink或者是ldsink.com都是柳总。
柳总说这个名字是 LinuxDeepin Sink 的缩写，
以及 Deepin 是一款很棒的 Linux 发行版，
Sink对应他的名字。
果然柳总是 Deepin 的真爱。

柳总现在基本只用Deepin。
（除了打dota2的时候）
我司程序员标配Mac电脑，
但只有8GB的默认内存和IOS的默认系统有时就不那么方便。
在柳总建议下和预算允许的范围内，
我换了一个神舟电脑+俩16G内存条，
他换了一个戴尔本子+俩8G内存条。
后来我的神舟天天蓝屏，
柳总嘿嘿一笑：“我猜是内存的原因，不如我们换一下”。
换了以后用着俩8G内存条神舟电脑的我果然不蓝屏了。
围观了事件全过程的张总惊呼：
“这就是柳总的内存转移之术！”

柳总是一个ACG御宅。
虽然广义上的说法可以介绍说柳总是动漫宅，
但其实我觉得他算是ACG Otaku，
也就是“在动画、漫画、游戏界都很沉迷的御宅族”的说法。
去年（17年）柳总发起了一波《刀剑神域：序列之争》观影活动，
同时表露了他作为松岗爱衣催婚协会会员的激动心情。
大学时期有一阵他手机铃声是石头门的OP《Hacking to the Gate》，
短信通知铃声是香菜的嘟嘟噜，
于是我总是瞅着他忘了开静音的上课时间戳他微信消息。

柳总是一个萝莉控。
他大概很吃萝莉音，
大学夜聊的时候，
讲到“你最看重女生身上什么特质”这个话题时，
柳总曾顺带讲过声音是很重要的特质：
“好的脸蛋总会衰老，
好的性格也许会变，
但是好的声音永远都是这么好听呀~
你看那些声优都是怪物~”

柳总是OI保送的交大。
柳总是雅礼中学毕业的，
我以前也到长郡中学读过一阵书，
有的时候就会聊到以前保送以后的放浪生活。
柳总说他们那个时候会集体去网吧，
打野的打野，打中路的打中路，好不快活。

柳总打dota，本名是先知。
读大学认识了室友以后第一件事就是互相报兴趣爱好，
柳总、郁翔和我都打dota，
小赖也有一阵被我们带的打起了dota。
柳总的本名是先知，
擅长的技巧是高台打野，
然后飞到中路gank影魔，
或者是出了大根以后电影魔，
或者是出了资源以后沉默影魔。
在11平台打天梯那阵，
在我们的分工之下，
柳总还用起了聊天流，
一边高台打野，
一边跟敌方影魔聊人生。

柳总有不少关系很铁的朋友。
以前大学的时候分分钟就可以靠柳总拉起五人黑，
（不保证黑店质量）。
有一次我们宿舍三人再加一个柳总好友四排，
一把游戏输了以后，
我感慨道“柳总你这朋友是有点菜啊”，
然后一看游戏的得分面板：
该玩家（柳总朋友）蓝猫英雄评分1分（正常分数是1000~3000分），
本场比赛-0分。
郁翔：-_-
我：=_=
柳总：+_+
后来我们也常常拉他一起开黑，
然后在“赢一场就睡”的flag下玩了一晚上。

柳总十分愿意分享他的知识。
大学夜聊的时候，
讲到“要怎么避孕”这个话题时，
因为郁翔和小赖都缺乏相关安全知识，
于是柳总兴致勃勃地给大家讲解了一波“安全期与避孕药”，
后来我们还拆了一个六盒装的杜蕾斯，
用了两个装些水玩了一下，
最后四个每人分了一个放抽屉里。
想着第二天阿姨清垃圾，
看到男生宿舍里突然出现的用过的杜蕾斯…
大家纷纷没心没肺地笑了起来…
毕业的时候宿舍四人清理抽屉，
都发现几年的一个过期杜蕾斯…

柳总还很有销售的天赋。
现在办公室里很多队友拿的是小米手机，
用的是小米插头，
测体温的是iHealth体温计，
都是拜柳总安利所赐。
柳总安利一样东西的手法异常纯熟：
介绍产品：“这个XX就可以买，功能有XX，是XX出的，解决了XX问题…”
打压竞品：“那个XX特别贵，没有XX功能，你看XX用的效果根本不好…”
瞬间到货：“我昨天刚买了这个XX，你要不要，你要的话我这个就给你…”
货款两清：“你扫我的付款码就好了，你看，再惠茶餐厅，多方便（笑眯眯）…”

柳总是金牛座的，对钱很有概念。
虽然柳总应该不太信星座。
柳总大学的时候就开始炒股了，
选课的时候还跟水哥发起过一波《证券投资学》的选修。
柳总对信用卡也颇有研究，
去年成功拉了好几个刷卡送星巴克的小伙伴入坑。
以至于后来我司做支付的时候，
大家都觉得这功能应该归属于柳总，
后来“代金券能不能叠加”这个月经锅也就自然而然地被柳总接下了。

靖哥哥只服柳总。
（语文老师说要有侧面描写，
想了想，就拿靖哥哥当靶子吧。）
靖哥哥是我司前端大佬，
不仅负责写一些JS文件（棒读），
还要负责前端整套服务器的搭建。
因为本身是大佬，
所以靖哥哥一直很屌，
除了跟柳总交流的时候。
每次靖哥哥都是鬼鬼祟祟地从走道走过来，
然后问柳总：“大佬，小弟问个问题，blabla…”
（不过每次在支付相关的问题上，
他们两个互怼的都很凶就是了）

柳总难以忍受落后的技术。
在之前的《我们是怎么升级到Python3的》一文中就讲过，
柳总充当了升级Python3整件事情的推动者，
把分锅、背锅以及一些大家不想做的锅相关的事情都做了。
发现了Git的Commit可以签名以后，
柳总又很开心地把他自己的Commit都签名了一波，
看着GitHub/GitLab上绿绿的认证标签，
柳总很是开心。

柳总其实是一个很内敛的人。
我想他大概会喜欢“木秀于林，风必摧之；堆出于岸，流必湍之；行高于人，众必非之。”这句话。
柳总虽然也很喜欢吃瓜（看戏），
但他一般不会直接表露他对事情的看法，
除非他忍不住了。
所以有的时候要逗柳总讲话，
就可以贱兮兮地发表一些有争议的观点，
比如“我觉得kafka是个解耦神器，什么场景都可以用”…

柳总也是懒人。
比如租房子，
柳总选自如是因为简单方便。
比如工具箱，
柳总把所有他常做的运维操作都记成了脚本。
比如答疑解惑，
假如别人有什么操作想问柳总的话，
柳总肯定第一反应是丢一个文档/脚本让他自己跑。
不过有些事情柳总也是很勤奋，
他的博客ldsink.com从14年开始一直保持着大概一月一更的频率。

柳总很白。
字面意义上的。
柳总以前也胖过一段时间，
有一次去面试候选人，
几轮面完以后谢老板出来笑着跟柳总说：
“刚才那个候选人说：‘前面那个白白胖胖的面试官很厉害啊！’”
受了很大刺激的柳总后面的两个月晚饭只吃沙拉…

柳总想笑的时候是忍不住的。
前阵子柳总又玩起了阴阳师，
然后一天晚饭的时候，
我眼睁睁地看他抽到了SSR·彼岸花。
然后柳总一副啊呀我真开心，
啊呀我要低调，
啊呀我不能在别人面前晒卡，
啊呀但我真的很开心
的复杂的开心表情。
这样的表情在大家围观紫光阁地沟油事件的时候也同样地发生过…

柳总和我虽然在同一家公司共事，
但其实任何时候我们两人聊天基本上不讲工作相关的事情。
反而聊的是“啥时候去交大办校友卡”，
“你搬家找房子怎么找”，
“XX银行卡真的福利很好你办一张呗，不用的话也可以给我”，
“你旧号不玩了的话，求给我登一下，好带我刷御魂”之类的琐事…

大概是一种“你的后背交给我了”的安心感吧。

这就是我的好友，柳宁宁。

Git的理念

Sat, 10 Feb 2018 16:01:31 +0000

本文尝试介绍一下Git的过人之处。
目标读者是想了解Git，
或者对软件设计有兴趣的人。

Git作为一个极其灵活的工具，
从修改单机游戏数据文件的版本管理，
到多人协作一起堆屎的协作开发，
使用起来都是十分趁手。

那么Git灵活的奥秘在哪呢？
大概是因为Git设计正交、实现扎实吧。

总览

Git里面的术语/命令很多，
但是它们可以归并成几个大类，
每个大类的概念都是正交的，
也就是说交叉概念很少，
不会有模糊的概念定义。
基于这样的设计，
Git与之对应地实现了一套扎实的命令系统。

Git里的概念有些难以准确翻译，
本文涉及概念词的地方尽量用术语表达。

比如经常用到的概念会有这些：

Line Diff
Commit
Branch
Repository
Remote

Line Diff

Git实现版本控制的方法是根据Line Diff，
推算出每个Commit具体改了哪些东西，
然后用多个Commit（实则是多份Line Diff）构建出所有历史。

这个基于Line Diff的先天设计决定了Git的一些特性：

可以存储所有历史。
我们常听到“Git是一个分布式的版本控制系统”，
这个指的就是Git不需要中心化的服务器，
你就可以做完所有操作。
因为本地存着所有的Line Diff，
所以“查看昨天被改过的文件名列表”这个操作完全可以离线完成。
对二进制文件不友善。
二进制文件是没法强行比Line Diff的。
所以假如用Git管理二进制文件，
Git只会显示一个Binary File Differ。
再把上面一条“存储所有历史”给叠加上，
就会出现今天提交了一个200M的文件，
明天后天我都修改覆盖了这个文件，
最后整个目录就有600M大了…
（也就是说一般不用Git来管理二进制大文件）
能检测文件重命名。
假如在一个Commit中，
从Line Diff的视角看，
删除的文件和增加的文件相似度很高，
Git就会判定这是一个重命名的操作。

Commit

Line Diff组成了Commit，
Commit是大部分Git操作的最小单位。
这个词既是动词，也是名词。

一个Commit包含了多种信息：

SHA hash：是根据line diff + 精确到秒的时间戳生成的一串唯一标识符
Author：写Line Diff的人
Committer：一个隐藏的属性，代表Commit的人
Date：包括AuthorDate和CommitDate
Message：Commit文本描述，Git会取Message第一行作为Subject，所以一般会遵循一定规范
Line Diffs：改动了哪些内容

这里还可以说的概念包括RootCommit、MergeCommit，
不过它们特殊之处不影响实际使用，
所以跳过它们，继续往下说。

Branch

多个Commit会组成一个Branch，
最初的Branch默认叫master（主干分支）。

Branch和Commit在很多命令里都是可以作为等价的操作对象的。
举个例子：

小成写了一天代码，
他在wechat这个分支上commit了很多次，
快下班了，小成想回顾一下今天的改动。
假设他的log长这样子：

> git log --oneline --graph
* f01c8d1 (HEAD -> wechat) refactor: improve project layout
* 2f9c867 feat: add rest api to create card
* 5d5242b feat: custom wechat card background
* 873e6ca fix: wechat card slow query
* 0dd06a9 fix: 500 when user unsubscribe
* fb91f98 (origin/master, master) feat: implement wechat card
* 176b4f0 feat: implement membership level
* 2727226 migration: add Settings.enable_level
...

那么以下命令是完全等价的：

# 查看从master到wechat的diff
> git diff master..wechat
# 查看从master到当前的diff（HEAD代表当前位置，也就是wechat分支）
> git diff master..HEAD
# 查看从master到当前的diff（HEAD是默认值，可省略）
> git diff master
# 查看master的commit到当前的diff
> git diff fb91f98
# 查看五个Commit以前倒当前的diff（master分支在五个Commit以前）
> git diff HEAD~5

所以也可以说“Branch是特殊的Commit”。
理解了这一点以后，
再去看大部分的Git命令，
发现它们都是git <operation> <range> -- <files>...这样的形式。

比如查看今天发布哪些内容就是git diff master..release，
把某个文件回滚到200个Commit以前就是git checkout HEAD~200 -- some/path/some/file.txt，
查看单个文件的改动历史就是git log -- some/path/some/file.txt

Repository

Repository包含了所有的操作历史。
git init命令可以初始化一个Repository。

一个Git Repository结构可能是这样的：

- .git/
- hooks/
- objects/
- refs/
- HEAD
- config
- ForgiveDB/
- README.md
- requirements.txt

这里的.git目录就存储着上面讲的Line Diff、Commit、Branch的所有历史，
就像上面二进制大文件的那个例子，
这里可能存了几百M的文件历史。

Remote

Remote就是放在别的地方的Repository。
同一个Repository可以添加多个Remote。

除了push/pull/fetch这些基本操作以外，
关于Remote还有一个很骚的设定：
Git支持本地Remote。

比如样例的命令如下：

# 假设在服务器上的 /home/lirian/chinese-calendar 路径下有一个 Repository
> cd /home/lirian
# 把它 clone 到某一个地方
> git clone chinese-calendar /opt/git/repo/chinese-calendar --bare
# 同个服务器上的另一个用户就可以 clone 这个 Repository
> cd /home/ldsink && git clone file:///opt/git/repo/chinese-calendar && git remote -v
origin file:///opt/git/repo/chinese-calendar (fetch)
origin file:///opt/git/repo/chinese-calendar (push)

这样的设计之下，
Remote/Repository是完全分离的，
不会因为断网就修改不了历史。
我们甚至可以把Remote当成一种特殊的Branch，
比如fork - pull request就是这种模式的一种应用。

尾言

文中讲到的不少例子有一些浅尝辄止，
读者有兴趣的话可以尝试思考实现一下这几个拓展问题：

关于Line Diff：改动的两个文件相似度多高，Git才会识别为重命名呢？
关于Commit：如何修改Commit的Author？GitHub上能看出来Committer么？
关于Branch：如何删除远程分支？git stash产生的Commit可以像Branch一样操作么？
关于Repository：删除分支以后，Git目录会变小吗？
关于Remote：文中用到的--bare参数是什么意思？

Git的设计理念中还有很强大的一部分是它关于历史（History）的管理，
那又是一个值得细说的话题。

总的来说，笔者眼中Git是一个科学且强大的工具。
Git优秀的原因在于它：

正交的设计：术语定义清晰，重叠概念少，表现张力强大。
扎实的实现：二级术语丰富，命令参数完善，贴合实际应用场景。

（完）

这就是我2018年的OKR

Thu, 25 Jan 2018 23:27:28 +0000

前阵子听了一位老师关于OKR很详尽的讲解，
受益匪浅。

引子

当时老师开题的时候，
举了“打地鼠”和“灭火”当例子。
以下是经过回忆加工的原话：

假如让你想一想，
去年一整年你做的三件最主要的事情是什么，
你能数的起来吗？

很多人是数不起来的。

因为很多时候没有目标，没有计划，
我们做事情就容易像打地鼠一样：
一会儿冒出来这个事情，很紧急，就先做这个；
又一会儿冒出来那个事情，很有前途，又做那个。

或者换个比喻，
假如我们要穿过一片到处都着火的地方，
才能到达目的地。
那其实只要规划好了，
我们只要扑灭我们路途上的火就行了。
其他烧着的火呢？
烧就让它烧吧。

（当时这段话产品经理小鱼表示感触很深，学到了）

通过这个小故事，
其实就想说明定目标本身是很有意义的。

那具体目标怎么定呢？
当然就是OKR了。

OKR

其实上次跟小米娅聊天的时候，
就学到了OKR相关的知识。

这次听老师又讲了一遍，
对两部分印象很深刻。

一部分是OKR本身的特性：

OKR 全称是 Objectives and Key Results （目标和关键结果）
可以对标 KPI (Key Performance Indicator - 关键绩效指标)

KPI会直接跟绩效考核挂钩，
而OKR一定不直接跟绩效考核挂钩。

当时讲到这里，
我听到了一句受震撼很大的话：
工作的奖赏就是工作本身

这种就属于我明白，
但是以前没能用语文直白表达出来，
结果被别人抢先说出来的道理。

很科学。

印象很深刻的第二部分是OKR的特性：

目标 (O) 要是一定时间内，定性的，鼓舞人心的，可以达成的。
关键结果 (KR) 要是定量的，陈述事实的，有挑战性的。

呃，这个要举例子就举的多了，
懒得写就不写了…
自己看看就行。

我的2018年度OKR

经历了好几天的思考，
我定下的OKR如下：

O1. 技术影响力大幅度提升
- 学习/理解/使用/掌握6个技术工具
- 成为1k+ star项目的主contributor
- 技术文章输出20篇
- 自己有233 star以上的代码项目
O2. 事业上做出极大贡献
- 团队的OKR完成率在80%以上
- review 10万行代码
- 当300场面试官
- 成为整个团队top 1%的人
O3. 保持幸福度爆满的状态
- 与亲人总语音时间超过1000分钟
- 跟女朋友争吵次数小于3次
- 帮助陌生人达50人次
- 新增500首红心歌曲

嗯！大概就是这样。

从今天开始，计时开始啦~

我的女友小米娅

Sat, 13 Jan 2018 08:06:16 +0000

小米娅本名叫吴莹莹，
不过她很喜欢Mia这个英文名和对应的中文名米娅。
不过注册微信公众号的时候，
“小米娅”已经被注册了，
于是最后纠结了好一会儿，
她选择了“一只米娅”这个听起来很精灵的名字。

认识小米娅的契机是因为我们一个公司，
她当HR，
所有人都认识HR。

印象中的小米娅就是身着深色系衣服，
气质高冷，
讲话信息量很高，
有种魔道中人的感觉。

公司要选年会主持人，
惯例是抓两个在职员工和两个实习生。
还是实习生的小米娅和我便被抓了壮丁。

由于要一起对串词，
得想办法活跃气氛，
我就有合适的理由讲一大坨电波系的冷笑话。
小米娅听了以后问：
这笑点在哪？
……

后来我发现小米娅和我是下班顺路的。
我回交大要两小时地铁，
她回华理也要一小时地铁。
于是那之后每天下班，
HR办公室门口就站了一个我…

有的时候小米娅会提很重的包下班，
（很直男的）我觉得女人都是弱鸡，
就想抢着帮她提。
小米娅都很礼貌地拒绝了我，
并顺便教了我一个道理：
女生的包，很多时候是整体搭配的装饰，
不可以因为大男子主义作祟而抢包哦。

小米娅的idol是林志炫，
而且小米娅会真的去追星，
不过小米娅心中，
林志炫作为老一辈艺术家，
她追星的心态更多是敬仰之情。
作为新垣结衣老公之一的我自愧不如。

小米娅人生唯一一次提前交卷，
就是为了去赶火车，
为了去听林志炫的演唱会。
演唱会结束以后小米娅和几个粉丝杀到了林志炫的酒店，
在大家一起拍合照的环节，
身材纤细的小米娅硬是挤到了第一排，
挽住了林志炫的手臂，
留下了一张小米娅跟她idol最亲密的照片。

小米娅自豪地把照片给我看，
我看着上面她一头红发惊呆了：
“你那时候怎么这么杀马特？”
“哦，大学的时候想染头发就去染了。”

小米娅做事有的时候很随性，
我很喜欢。
上周我们在家吃饭，
讲到洗碗真特么麻烦，
突然灵感一闪：
“饭堂用的铁盘子洗起来很方便！”
“那个沃尔玛有卖！”
于是我们决定就用饭堂铁盘子吃饭了。
可能以后朋友圈晒厨艺的时候，
会有点怪。

说回杀马特。
小米娅染了红发以后去初中接她妹妹放学，
她妹妹的同学都惊呆了。
她妹妹倒是很淡定：
“我姐真帅！”
不过后来小米娅要实习面试了，
为了稳妥，头发还是染了回来。

我经常会求小米娅：
“你啥时候染个头发呗…我光看照片就觉得老帅了…”
小米娅：
“不染，滚”

小米娅大学是学德语的。
她跟我讲大学去德国交流，
然后周末去了周边玩耍，
科隆大教堂真壮丽云云。
我说：科隆大教堂！我以后也想爬！
小米娅：？？？

小米娅知道我很喜欢玩游戏，
我跟她讲了很多刺客信条/Dota/文明/游戏厂商的故事。
作为交流，
小米娅也跟我讲了很多生活大爆炸/哈利波特/神探夏洛克/柯南的故事。

不过虽然小米娅看柯南，
但她不是二次元（此处有争议，我想不到一个既合适又中庸的词）
本来想拿South Park/Rick and Morty/Fate这些动画安利她，
但小米娅不吃安利。
最终小米娅从头到尾看完的一部动画就是《好想告诉你》。

小米娅是人生第一次恋爱，
大概她从《好想告诉你》里找到了跟《冰果》一样的蔷薇色的世界吧。

不过这里比较烦的是她有时会缠着我，
要我讲以前的恋爱故事。
我又不能不讲，
于是我每次只能用教科书上的讲故事方式，
从背景，到发展，讲到矛盾点，最后再总结经验教训。

15年以后小米娅和我都转正工作了，
她成了HR，要看很多简历。
于是每次我跟她讲了很多什么叫科班出身，
什么是软件工程，
Java和JavaScript是什么关系，
数据库是什么概念。

后来我去面试的时候，
一个面试官问我问题：
“假设我不太懂技术，
你能不能用通俗的语言解释一下，
什么是软件工程？”

我讲完以后面试官又很好奇的问我：
“我觉得你讲得非常好啊，
你平常会思考这些问题吗？”
我便跟面试官吹捧了一下我的女朋友。

工作里小米娅经常要帮外国人招人。
有一次一个老外要招Linux初级运维，
这个老外跟小米娅说他最近很忙，
没时间面试，要小米娅帮他做电话面试。
于是那阵子我被小米娅问了一万个问题…
后来成功招到人了，
老外非常开心地发了一封感谢信给中国区所有HR。
（虽然这么说，但是我们是小厂，一共四个）

作为HR，
小米娅还会接触到很多敏感信息，
主要是薪酬。
不过小米娅非常有职业操守，
她从来不会跟我透露任何敏感信息，
即使后来小米娅和我都到了不同的公司。

当然，我也很有职业操守。
我也不会把公司代码给小米娅看的。

小米娅现在的公司是家外企，
特别狼性文化。
就是那种你干得好，你牛逼，
你干不好，你走人的公司。

小米娅和我都不太喜欢这种非常有侵略性的文化。
不过小米娅刚入职没半年，
好像就要当主管了……

平常小米娅和我都很忙，
小米娅7点起床，8点出门，
我9点起床，9点出门。
晚上小米娅8点到家，还要做饭，
我10点回家，要洗她不想洗的碗…
（不过最近小米娅特别勤奋，
都自己洗碗了）

平常住在一起，
小米娅不喜欢洗碗，
我不喜欢洗/晾/收衣服，
分工明确。
不过我们都喜欢干活的时候外放歌曲，
于是家里有时响起林志炫的歌声，
有时响起《电音之王》……

小米娅和我租的是两室一厅，
虽然是情侣，
但平常都是各睡各的。
她心安理得地大字型霸床，
我也心安理得地听歌写程序到夜深。

小米娅收到的第一个礼物是一个特别可爱的，
摸起来像柴犬，看起来也像柴犬的粉色小熊玩偶。
小米娅和我都十分喜欢这个玩偶，
于是我们决定给它取个名字，
一番讨论以后，
这只小粉熊就叫“吴建国”了。

小米娅的理想之一是环游世界，
她在旅行之前会做极其详尽的攻略。
就像 @苍南派说的一样：
两个人旅游，通常是一个人负责订来回车票酒店民宿景点门票计划好目的地路线行程衔接整体开销查看好天气情况帖子攻略网友好差评想好怎么看怎么玩怎么吃，另一个负责当弱智。

我就是那个开心的弱智…

这么说来，
小米娅好像快醒了。
这次小米娅的故事就先讲到这里吧，
下次见~

我是怎么实现《用弹幕玩GBA游戏》的

Sat, 06 Jan 2018 18:58:33 +0000

大概是大二的时候，
我在TwitchTV上看到了一个极其精彩的Idea。

背景

TwitchTV是外国的一个主要做游戏直播网站，
观众可以打开网页观看游戏直播，
每个人都能随时发弹幕表达自己的想法。
弹幕是啥？

依赖于发弹幕万人同屏的这个设定，
TwitchTV做了一个很好玩的功能，
就是“几千人玩操纵同一个角色，玩同一个游戏。”
详情可以参见Twitch Plays Pokemon这个维基词条

当时看到这个消息，
我也去玩了一下，
感受是：特别好玩！！！

几千个人同屏玩游戏的话，
最大的感受就是混乱，
这也是最棒的体验。
大部分玩家是冲着通关的目标去玩的，
所以总体看来，角色的行为是有目标性的。
但是也会有一部分玩家以捣乱为乐，
在一些精细操作的时候（比如收服Pokemon的时候）
就会额外混乱。

最终整个游戏（或者说社会实验）在混乱中前行，
经过了16个日夜，
最终打过了四大天王，
完成了通关壮举。

OK，前面都是背景介绍，
那么看到这么好玩的一个东西，
我的心痒了很久：
我也想实现一个类似的功能！

实现

就像把大象塞冰箱里需要拆解步骤，
为了实现“用弹幕玩同屏GBA游戏”这一点，
我们主要要做的事情有如下几点：

申请一个直播间
获取直播间的弹幕
实现从弹幕到键位的映射
用程序操纵GBA模拟器

当然，我们这个拆分非常的粗略，
而且会有很多具体的问题，
我们一个一个地来看。

申请一个直播间

我要没记错的话（懒得去查资料验证了）
TwitchTV的同屏玩游戏功能应该是官方实现的，
不是某一个主播或者是我这样的第三方程序员实现的。
平台自己实现的话会有非常多的自主权，
而且可以给到游戏本身的推广，
一波活动推出去不论是效果还是效果都会更好。

但是毕竟人微言轻，
我们普通人类还是要从头开始，
从申请直播间开始。

申请直播间的话主要是涉及到直播平台的选择，
因为我一直都是A/B站用户，
所以直播平台基本上就是斗鱼（A站生放送）和B站直播之间选一个。

最终我两年前注册了一个斗鱼直播间
（打个广告，从来不播的直播间：douyu.com/lisp）

第一步算是做完了。

获取直播间的弹幕

这个是个非常interesting的问题。
首先他受前置问题的影响，
带来的现实问题是每个直播平台获取弹幕的难度是不一样的。

斗鱼和B站直播相比，
看斗鱼的人肯定是更多的，
但是受氛围和观众群体的影响，
会为B站写插件的程序员更多_CITATION NEEDED_。

但毕竟我们在上一个步骤选择了斗鱼，
还是得从一而终。
于是两年前我就在知乎关注了《如何获取斗鱼直播间的弹幕信息？》这个问题，
顺便学习了一波socket相关知识（对，这句话反映了我的真实水平…）

当时没有一套好用的库，
我又懒得自己钻研，
所以就卡在这里了。

后来我在GitHub闲逛的时候，
发现itchat的作者写了一个包，
支持获取各大直播平台的弹幕，
感觉就是我要的轮子！
于是我点了一个star先马克着。

今天是2018年1月，
这个库最近的更新是2017年5月，
有大半年没更新代码了。
正式采用之前我试了一下，
斗鱼的弹幕是没问题的，
不过B站的弹幕因为是直接解析网页原文拿ROOMID的，
已经失效了。
又因为这个库（或者说littlecoder这个人）不是很Pythonic，
于是我心中又暗立一个flag，
fork了这个项目，
想着啥时候摸鱼摸够了就去改进一波。

于是最终我采用了danmu这个库，
几行代码就成功地获取了斗鱼弹幕，
大概代码（伪）如下：

import danmu
client = danmu.DanMuClient('https://www.douyu.com/lisp')
@client.danmu
def receive(message):
print('[{}] {}'.format(message['NickName'], message['Content']))
client.start()

实现从弹幕到键位的映射

这个没什么可以说的，
就是业务逻辑/苦力活。
简单。跳过。

用程序操纵GBA模拟器

好，这里首先有个坑。
我们回忆一下，
最开始我们的目标其实是“实现用弹幕玩GBA游戏”，
现在的这个小步骤被回归成了“用程序操纵GBA模拟器”。
这模拟器的需求是哪冒出来的？

嗨呀，这个是有苦衷的。

首先，我对GBA的回忆除了实体机，
有一半都是VisualBoyAdvance.exe这个模拟器给的。
还有就是理论上我们也可以实现Web版的，
或者自己撸一个GBA模拟器，
但那样又相当于额外的工作量了。
所以基于“把我不会的目标拆成我能做到的小步骤”
和“鲁迅说过，不要重复造轮子”这两个设定，
我就把“用程序玩GBA游戏”拆分成了“用程序操纵GBA模拟器”+“用GBA模拟器玩GBA游戏”（现成的）这两个任务了。

OK，我们来现实地看第一点：
“怎么用程序操纵GBA模拟器”。

在我的脑海中，
假如用Python来实现，
基本上这个就是Python调用windows库 + windows库给程序传递信号 + 程序接收信号达成效果，
这样一套combo下来就行了。

虽然我平常开发环境是windows，
但其实我对windows的接口是一窍不通（暴露水平 x2）
不过不懂可以问啊！
于是前几天我问了一下身边的windows大拿hulucc，
他表示windows有个叫sendkey的API可以做这个，
不过只能操纵active window。
后来他又查了一下，
跟我说Python里有个pywin32的库可以调用windows接口，
又发了一篇文章 How to Build a Python Bot That Can Play Web Games
给我参考。

学习了这么一大段以后，
我十分感动，
然后自己找了个另外的库keyboard（雾）

事实是后来我回来研究了一下，
用windows接口肯定能达到我的目的，
但是问题是pywin32或者是类似的pypiwin32这俩包没有合适的pip release要手动安装，
这让我很不舒服。
刚好google的同时，
我搜到了另外一个python库keyboard，
它的主页长得还蛮好看的，
也能达到我的需求，
不错，就这个了。

于是实现了接收弹幕+发送按键的代码（伪）就大概长这样子：

import danmu
import keyboard
import constants
client = danmu.DanMuClient('https://www.douyu.com/lisp')
@client.danmu
def receive(message):
print('[{}] {}'.format(message['NickName'], message['Content']))
content = message['Content'] # 主要是新增了这行和下面的if
if content in constants.valid_keystrokes:
keyboard.send(content)
client.start()

一个小坑

这里还遇到了一个小坑，
简单来说就是VisualBoyAdvance这款GBA模拟器（以下简称VBA）
它应该是通过监控键盘事件来转化键位的。
（此句描述不够专业）

转化成代码语言就是keyboard.send(content)这行代码对VBA不起作用。
经过思考加尝试以后，
最终使用了keyboard.press(content) + time.sleep(0.02) + keyboard.release(content)三个combo达成了效果。

最终不禁要感慨一下：
上面这段描述里的经过思考加尝试，
就是写程序这件事情最痛苦也是最美好的所在了。

总结

上面讲的比较零碎，
总结下来：

为了做到 “用弹幕玩GBA游戏” 这个事情，
被拆分细化完成的任务有这些：

注册直播间，选了斗鱼。
获取直播间弹幕，平常关注一波信息，最终用了danmu这个库。
实现业务逻辑。
用程序操纵GBA模拟器来玩GBA游戏，使用了keyboard库发送键位信息。

最终的成品在我的GitHub上：LKI/danmaboy这个项目，
有效代码就100行，就在danmaboy/__init__.py一个文件内。

一下午就写完了，
不过中途摸鱼思考的时间用了几年（惭愧）

下午写代码的时候我还做了一个尝试，
就是开着直播写代码，
不过因为没人看（现实的原因），
所以总体感受跟小黄鸭编程差不多，
写一会儿，就紧张地想一下思路，
效果意外的不错。

最终成品出来以后，
试着在直播间里跑了一下，
~~创业失败~~遇到了一个基石上的失误：

因为是游戏，所以普通的弹幕延迟在这个项目上会放大到极度影响游戏体验

基本上就是发一条弹幕，
15秒以后才会有对应的游戏变动，
别说TwitchTV那样的效果了，
就是基本的自己玩玩都玩不动…

叹气。

不过好歹是我心里很多idea之一了，
这篇文章也算是给这个项目画个句号吧。

我的心中还有很多未竟的事业，
有兴趣的话，
欢迎和我交流噢~

下次见。

直播时的画面截图

一种简单的鉴权方式：JWT

Sat, 09 Dec 2017 20:07:17 +0000

这是一篇关于 JWT(JSON Web Token) 的简短介绍。

什么是JWT

JWT, 全称是JSON Web Token，
是一种易于使用、无状态的鉴权(Authorization)方式。
简单的来说，就是
Server端把JSON数据经过加密做成token，以授权给Client端。

多说无益，上代码，举个栗子。

当Client端登录完成以后，
Server端要返回一个7天有效的token，
那么对应的Python的样例代码会是这样的：
（使用了PyJWT包：pip install pyjwt）

import time

import jwt

exp = int(time.time()) + 86400 * 7 # 失效时间
user = 'liriansu' # 用户表示
key = 'hunter2' # 密钥
payload = {'exp': exp, 'user': user} # JSON 数据
token = jwt.encode(payload, key)

print(token)
# token可能会长这样子
# eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.e30.EoKoMCjq_zGqUg5HDfqw4EN7EiG6gMjkUZle0uGJDGU

关于hunter2也有个梗：弱密码hunter2

然后Client端每次在authorization header或者是query string里带上token。
Server端收到请求的时候，
用payload = jwt.decode(token, key)验证权限就行了。
验证通过以后，payload中就是整个JSON数据。
理论上你可以往token payload里塞任何_非敏感_数据。

所以综合来说，
假如使用JWT作为鉴权方式，
有以下几个特性：

Client端不用管任何加密/解密，只用存token，在请求里面带上就行了。
Server端可以实现不依赖外部存储鉴权，所有的数据都丢在token里。
也就是说鉴权这一步不需要File/MySQL/Redis之类的数据库，也能知道用户身份。
因为token带失效时间，所以需要在失效前/后再刷新token。

好了，以上就是关于JWT的所有描述了。
本次的简单介绍就到此结束。（雾）
（不过上次关于Hawk的介绍大概就是这样的）

关于JWT的更多说明

讲了这么多，实质上就是用个JSON数据当token，
这破token真的安全吗？能伪造吗？

emmmmmm, 好问题（表示这个问题很尖锐，难以正面回答，准备迂回）
JWT使用很广泛，久经考验，大家都在用（表现了我也不懂，应该不会有问题吧？的一种从众心理）

认真地发表一下个人意见：
首先token/key泄漏了，
后果基本是跟其它鉴权方式一样严重。
其次JWT可以选择合适的加密方式，
加上合适的key是基本伪造不了的。
还有就是在JWT之外，
一定要用HTTPS！
不用JWT相当于没有门禁，
不用HTTPS基本是不穿内裤了。。。

我想了解更详细的JWT生成/验证过程

具体说明请参照来源 RFC7519 - JSON Web Token (JWT)

简单的来说，JWT是由以下三部分组成的：

第一部分指定了加密算法(alg)和token类型(typ)。
第二部分就是我们定义的payload。
第三部分是由加密算法产生的签名。

获取了三部分数据以后，
分别用base64加密，
把最末的等号去掉，
再用小数点连在一起，
就是一个token了。
验证的话，基本就是把这个过程反过来。

我去，那token里的信息就是明文的啊？

是的。
所以token里不要带任何敏感信息。

文档上把payload里带的信息叫Claim，
有这么几个可选的Claim：

iss: Issuer, 签发方。
比如这个token是微信签发的，
那么可以是{'iss': 'wechat'}
aud: Audience, 接收方。
比如王者荣耀想用微信登录，
那么可以是{'aud': 'king-of-glory'}
exp: Expiration Time, 失效时间。
使用的是整形Unix时间戳，
关于时间戳可以看看《互联网上的日期和时间》

RFC7519里面还有一点很好玩，
就是上面每一个Claim最后都加了一句Use of this claim is OPTIONAL
（RFC2119还定义过啥叫OPTIONAL）

也就是说我们可以往payload里丢任何东西。
只要符合这种加密/解密/鉴权的方式，
我们都可以说“我们用了JWT”。

那token会不会很大？

有可能会。

所以payload里的东西能少则少，
看文档里，连issuer -> iss, audience -> aud这种地方都给省了好几个字符。

还有就是传输JWT的时候，
相较于放query string里，
更推荐放在Request Headers里面。

与其他鉴权方式的对比

详尽的比较超越了本文的范畴，
（写这句话好爽，可以少查一万个资料）
下面就用个简单的表格来对比一下_我了解的_几种鉴权方式吧：
JWT, OAuth, Session, Hawk

	JWT	OAuth	Session	Hawk
易用性	容易，就一个token	麻烦，要用Refresh Token刷Access Token	容易，用Cookie就行	麻烦，每个请求都要单独计算header
泛用性	各种场合都适用	带三方授权的场合特别适用	还行吧…	能用header的都适用
安全性	跟别的方案差不多，key泄漏了就完蛋了	Auth Server安全就行，~~我才不管Client~~其它的跟别的方案差不多	还行吧…	我！能！防！中间人攻击！
接受度	有一定安全度，client端很喜欢，用的还是很多的	繁琐和安全的折中方案，很多大厂都用	真的广…	目前只听说了我司在用Hawk

其它感受

JWT全称叫JSON Web Token,
小心别写了类似jwt_token这样的变量名了（语义重复）。
RFC7519还定义了JWT读起来是类似于jot的发音。
然而实际中交流都会说JWT（怕听不懂）。
JWT说是说用同一个key就行了，
不过我们在项目实际中还是根据不一样的user用了不一样的key。
（同时也用了数据库）
假如payload里带了失效时间，
理论上JWT签发后是不会失效的，
也就是Server端管理不了这些token。
（所以可以加个数据库来管）
（好像变复杂了）
用JWT想做“记住登录状态”这个功能的话，
可以设定token失效期比如是7天，
然后用户每天登录的时候刷一次token。
这样除非用户一周内都没登录，
才会请求重新登录。
我对互联网安全的认知是真的有限，
经常看文档，
一句话学到三四个新的词。
还是要多学习一个啊。
所谓苟日新，日日新，又日新是也。

视差

Mon, 04 Dec 2017 22:29:14 +0000

蚍蜉和大树是很好的朋友，
蚍蜉常常站在大树头上跟大树聊天。

两只生物从诗词歌赋谈到人生理想，
无话不谈，谈了又谈，
所有的观点都无比契合。

这一天他们看着遥远的天空，
蚍蜉不禁感慨道：“天真的蓝啊。”

出生在悬崖边上的大树一动不动，仿佛出了神：
“是啊，这天空的蓝，比海面的蓝更宁静。”

看着视野远方的海天分界线，蚍蜉也不禁感慨道：
“对啊，海洋的蓝深邃，天空的蓝给我一种忧伤的感觉。”

大树摇了摇身上的叶子：
“我倒觉得春天的时候，叶子的颜色才更忧伤。
天空的蓝给我一种生机盎然的感觉，我很向往。”

蚍蜉觉得很奇怪：
“不对呀，春天的绿叶才是生机盎然吧。”

大树笑了：
“你可不能把生物规律加到颜色感觉上，
绿色本来就是忧郁的，
尤其是春天叶子新芽的那一抹淡绿。”

蚍蜉没有说话，想了想，提了个问题：
“那大树，你能不能描述一下你眼中的绿色是什么？”

“绿色啊，就是春天万物生长时候的颜色啊。
比如绿叶衬红花，老树发绿芽，
这阵子在我们这跑来跑去的那个年轻人，
帽子也是绿的。”

“唔，我不是问绿色在现实生活中的投影。
我想知道你是怎么看绿色这种颜色本身的，
更重要的：你对这个颜色的感觉。”

大树侧着脑袋想了想，说：
“其实吧，我看到绿色，
会有种很平静，很忧伤的感觉。
就有一种我整棵树都会沉浸在绿色里，
随着我越沉越深，我整个颜色也越来越淡。
深色的绿色就会有一种特别深邃的感觉，
就像这个颜色本身就是自然赋予的，
深不见底，吞没灵魂。”

随着大树讲下去，
蚍蜉的眼神变得越来越锋利了：
“大树，我觉得，我们看到的颜色不一样。”

还沉浸在颜色感觉中的大树一愣：
“怎么不一样了？”

“我跟你讲一下我眼中的绿色吧，”
蚍蜉想了想，描述道：
“绿色给我一种生机勃发的感觉，
我指的是光看到这个颜色，
就觉得它里面蕴含着生命的能量，
看到它会感觉特别平静。
这种平静跟蓝色不一样，
蓝色是让你没有想法，
绿色会让你觉得生命本身就是这么美好，
会被温柔地环绕。”

大树仿佛意识到了什么，
缓慢地说道：
“我觉得，你描述的是蓝色。”

蚍蜉点了点头：
“对，刚才我也觉得你描述的是我眼中的蓝色。”

大树沉思了一下：
“有趣，这么看来，我们眼中的蓝绿色其实根本是反的。”

“是的。但是我看到这个颜色，我叫它绿色，
你看到这个颜色，你也叫它绿色。
完全一致。”

“对。我小时候知道这是绿色，是家人教我的，
想必你也是这么认识颜色的。
假如我们不交流对颜色本身的看法，
我们就永远不会发现我们眼中的蓝、绿色其实是非常不一样的。”

“这就是视差。
不止蓝、绿色，说不定我们眼中的世界都是非常不一样的。”

小云、庄子、惠子三个人讨论完了这个故事，
击掌而笑。

庄子感慨道：
“妙啊，我得把这个故事写下来。”

惠子想了想，评论道：
“这样写的话，太直白了。
怕是读者只会看字面的意思。”

小云笑着拍了一下惠子：
“放心，庄子这个人可是狡猾得很，
他肯定会彻底换一个故事皮的。”

庄子也笑了：
“既然小云你这么说我狡猾，
那我可就要把故事里的你换成一条鱼了。”

惠子担心地问：
“这样会不会被读者曲解了故事的意思啊？”

“没关系。
这也是视差。”

Python项目自动化部署之一：举个栗子

Thu, 23 Nov 2017 16:49:57 +0000

本文主要讲述一下我司
（一个成长中的创业公司）
目前的代码发布流程用到了哪些工具。

发布工具：Jenkins

我们用的发布工具是很多公司都在用的Jenkins。
举个栗子图，
在Jenkins Server上可以一键发布后端服务器代码：

按下 Build按钮以后，
发生的事情如下：

在 Jenkins服务器上触发预先配置的 Bash脚本
- git命令获取到最新的代码版本，切换合适的分支
- ~~执行代码风格检测和单元测试~~自从使用了付费版GitLab后，本功能已切换至GitLab CI了
- 安全检查通过以后，使用fab命令部署代码

发布命令：Fabric

这里的fab命令用的就是Python的Fabric库，
这个库类似ansible，
主要包含两套功能：

本地命令集成。
这点大概跟 Java 的 ant, gradle,
或者是 JS 的 npm run 有类似功能。
都是可以把数个操作集成到一条简单的工作流命令里。
远程ssh工具。
Fabric里基于ssh，
实现了一套方便的远程命令接口，
比如这么一段代码就可以把配置上传到远程服务器：

from fabric.api import * # NOQA
# 不用试了，这里的两个都是假的domain，对应放上ssh的host/user即可
env.hosts = ['www.kezaihui.com', 'zaihuiwebserver-814613977.cn-north-1.elb.amazonaws.com.cn']
env.user = 'saber'
def update_supervisor_config():
put('./supervisor/*.conf', '/etc/supervisor/conf.d/', use_sudo=True)
run('supervisorctl update', use_sudo=True)

但Fabric有个比较蛋疼的地方就是它只支持Python2，
假如要用Python3的话，
可以使用Fabric的一个fork分支Fabric3，
Fabric3与Fabric大部分功能等价。

只想用里面本地命令集成这部分功能的话，
还有一个库叫Invoke也提供了类似的功能。
这个库主要是名字特别帅，
dota2里面的卡尔就叫Invoker（祈求者）。

进程管理：Supervisor

在正式环境中，
为了保证服务器进程的鲁棒性，
我们使用了 supervisor 来监控进程状态。

一个简单的 nginx supervisor 的配置会长这样子：

[program:nginx]
command=/usr/sbin/nginx
autostart=true
autorestart=true
stdout_logfile=/var/log/supervisor/nginx.log
stderr_logfile=/var/log/supervisor/nginx_error.log

把配置文件放到 /etc/supervisor/conf.d/nginx.conf 以后，
就可以使用一系列命令把服务起起来：

$ supervisorctl update # supervisorctl 是 supervisor 的命令行工具，更新一波配置
nginx STARTING pid 1000, uptime 0:00:00
$ supervisorctl status # 查看进程状态
nginx RUNNING pid 1000, uptime 0:12:34
$ kill -9 1000 # 模拟各种波动，干掉 nginx 进程
$ supervisorctl status # 再次查看进程状态，可以发现 supervisor 自动重启了
nginx STARTING pid 1020, uptime 0:00:00

总结

负责发版的工程师，
可能只在页面上点下了 Build 的一个按钮，
实际上的流程是这样的：

Jenkins 触发了配置好的 Bash脚本。
里面 Bash 脚本跑了 fab 命令。
fab 命令执行了代码上传的工作，本质上是通过 ssh 执行命令。
最终用 supervisor 开启/重启了进程服务。
发版完成。

以上大概就是我司目前自动化部署的简陋介绍。
升级之路漫漫，
还是有很多东西要学习/实践/掌握的呀。

原文链接，作者 @苏子岳

本文版权属于再惠研发团队，欢迎转载，转载请保留出处。

怎么使用搜索引擎

Sun, 19 Nov 2017 21:52:07 +0000

我就是这么用的。

平常学习/工作过程中，
我经常提问和被提问，
有时会很惊讶地发现：
似乎我十分擅长回答别人的问题。

于是我自豪地内省了一下，
发现了“表面上擅长回答问题”的原因：
我很擅长利用搜索引擎。

于是我又灰溜溜地自省了一下，
发现了“擅长利用搜索引擎”的原因：
我掌握了一些小技巧。

我决定把这些小技巧给记下来。
熟练学习、理解、运用、掌握以后，
相信你也能成为一个优质的谷歌UI的。

不用百度，尽量用谷歌

在大陆的人类中，
使用最广的搜索引擎应该就是百度了。

但我不喜欢用百度，
一些主观的原因主要如下：

口碑不好，可被替代。
因为种种原因（假药/推广/泄露用户信息），
百度的搜索口碑不好；
而且友商搜狗(sogou.com)也能顶替搜索功能。
那我更愿意选择口碑好的产品。
内容更新不及时。
举个栗子，GitHub Issue里的最新内容，
百度就很少收录[CITATION NEEDED]。
而很多代码里的一些冷门报错，
收录的就更少了。

个人来说，我推荐能访问谷歌搜索的友人，
都可以使用谷歌搜索。
虽然谷歌的中国本土化做的不一定好，
但是像“怎么判断煤气泄漏”
“大哥喝冰阔落是什么梗”
“一点点哪个味道比较好喝”都是可以搜到合适的答案的。

访问不到谷歌的大陆人类，
也可以使用必应、搜狗等代替。
我个人平常会用搜狗。

假如程序员朋友，
想了解“不用百度搜索”的更多信息，
可以读一下酷壳的倡议：《“作环保的程序员，从不用百度开始”》

找到X问题

我之前一直以为XYZ问题是个广泛使用的说法了，
没想到居然好像是我先提这个说法的。

XYZ问题的描述是“有的时候我们想解决的是X问题，但是我们却纠结于Y问题，最后却陷入了Z问题的陷阱里。”
归纳一下就是：找到问题的根源

比如文章里提到的打字机效果，
就是搜索X问题一个很好的例子。

再比如平常写代码会遇到的第三方库报错的问题，
程序报的错一般都比较原始：
比如channel 0: open failed: administratively prohibited这种。
有的时候看到报错，
我们会不自觉地先思考几步，
觉得可能是SSH channel遇到了权限问题，
然后我们就搜索了linux ssh channel permission，
结果答案就海了去了。
这里最好的做法是直接用裸的报错信息去搜，
因为原始报错信息就是描述根源问题的最准确描述。

用正交的搜索词

其实上一节我们搜linux ssh channel permission的时候，
我们已经用了正交搜索词的技巧了。
这里借用数学术语正交，
说的是几个搜索词之间尽量相互独特，互不关联。

比如假如没有文化的我，
忘了朱自清先生的名篇叫什么名字，
可以搜“父亲橘子不要动”，
就能搜到《背影》一文。
~~（其实会搜到梗/段子/表情包）~~

比如我知道DC漫画跑得快的是闪电侠，
忘了漫威那边跑得快的是谁，
那显然我们搜“跑得快一日千里到过很多地方”这样相近的词语是搜不出快银的，
我们要用“漫威跑得快对标闪电侠”当关键词来搜索，
就可以得出合适的结果了。

理解结果

搜索引擎大部分时候不会给出确切的答案，
给出的会是一个网页。
假如搜的是报错的话，
很多时候会给出一个问答论坛页面，
或者是讨论过程。

这就要求我们能从一整个页面中抽出对我们有用的关键信息，
而且有的时候还要分辨谬误信息，
这里就是经验发挥作用的地方了。
你只要去尝试下载一个中文盗版软件，
就可以掌握“抽出有用信息”的技巧。

假如是写程序的搜索的话，
你得了解Stack Overflow/GitHub Issue的一些基本方法：
比如Stack Overflow上高赞很多都是好几年前的答案，
要注意语言/库的版本；
以及GitHub Issue emoji最多的答案一般都有用等经验论。

还有很多时候可能你是一个搜索引擎UI，
你要负责把结果二次解释给其他人。
那首先确保你解决的是X问题的基础上，
最有用的就是换位思考，
确定对方的立场/理解力/需求，
再用对方能接受的语言讲述给他。

总结

不用百度，尽量用谷歌。
找到X问题。
用正交的搜索词。
理解结果。

只要做到这几条，
你就是一个合格的搜索引擎UI了。

再佐以温和的态度，
良好的伪装，
以及不会被看透的高深。

恭喜你，你就成为了他人眼中的大佬了！
（撒花）

程序员之逻辑

Tue, 31 Oct 2017 22:05:35 +0000

我有时会突然意识过来，
写程序这件事情给我带来了深远的影响。

利益相关：
以下皆为本人自身想法，
与广大的可爱的程序员们不一定有关。

苏·格拉底曾经说过：
“一个人要先不断地剖析自己，
再不断地剖析自己，
最后不断地剖析自己，
他才是个伟大的人。”

苏·格拉底：
我不是，
我没有，
别瞎说啊。（否认三连）

苏格拉底：
别乱在外国人名中间打点。

在此，我就记录一下平常生活中的小事，
这样说不定可以窥斑见豹。

0

跟计算机打交道久了，
非常清楚程序都是按照流程来的。
所有所谓的 Bug 都是某个地方的计算机逻辑，
没有跟人类逻辑匹配上所导致的。
所以现在修 Bug 的时候，
虽然也会像以前一样高呼着“这不科学”，
但其实我心里知道，
这很科学，
而且外国古人不是说嘛：
Where there's a bug, there's a fix.

人类也是一样的。

我们做的所有决定，
所有结果，
都是由一个决策树生成的，
这棵树或深或浅。

我今天心情好，
突然坐到奶茶店里喝了一杯奶茶。
在旁边分手的小情侣，
用苹果电脑办公的小哥，
几个叽叽喳喳的大妈，
都像是钱钟书说的一样。
不过都是电台换台，
东一句西一句听得零碎，
但他们都是有自己完整的故事的。

所以看事情，
知道了来龙去脉以后，
我总忍不住感慨一句：
这很科学。

1

乌托邦世界里，
大家都很科学。
然而实际生活中，
总会有取舍。

比如 Vim vs Emacs,
PC vs 主机,
青轴 vs 红轴
等等话题，
现世中的我们总要做出选择。
而事实告诉我，
因为某一时刻，
我们的用户习惯、
用户量、
团队氛围、
外部环境总是固定的，
所以虽然没有最优解，
但我们一定可以选择更优解。

比如阿里编码规范里写到的超过三个表禁止 join，
我非常理解这里的道理，
但是我自己做项目的时候恕做不到。
或者说按网上一部分的说法，
好的男朋友要清楚包括口红色号在内的很多信息，
那我更愿意尊重独立个体，
毕竟想了解dota新版本具体改动内容的人也是少数…

拿最开始的 Vim vs Emacs 这个经典话题来举例子，
在两边都用过以后，
的确知道为什么说一个是编辑器之神，一个是神用的编辑器了。
但具体到每个人的每个编辑环境，
总会选择一种搭配方式，
让他陷入最舒服的境地中。

01

万物科学 和 最优解 这两点叠加起来，
有一个结论就是永远要保持开放性的心态。
假如我们秉持着
世界上，15岁之前出现的都是已有的平凡事物，15到30岁出现的都是改变世界的发明，30岁以后出现的都是什么垃圾玩意啊。
这样的心态，
那我们就会早早地陷入 local optima.

举个栗子。
业务代码写多了，
人我就容易陷入套路代码的惰性里。
前阵子和产品经理讨论一个需求的实现，
说到一个点，
我很自然地说：“这实现不了。”
但产品经理又好奇地/疑惑地/质疑地多问了一句：
“为什么呢？”
那一刻我心中一愣，
对啊，为什么呢？
于是后续展开了更深刻的讨论。

总的来说，
我十分敬重学习能力，
我也十分喜欢/敬仰那些学习能力很强的人。

在面试时跟候选人聊天的时候，
我很喜欢问一个问题，是：
能不能讲一下，你做过的项目里，你最喜欢的一个？
有些同学会突然激动起来，
抓着你讲一个完整的故事。
比如最开始是某某原因，
然后本来是想怎么样的，
后来又因为什么样的原因，
学到了什么什么。
在这样的交流里，
不仅我能学到不少东西，
我也能看到他身上的成就和成长。

11

所以我很愿意当一个好奇宝宝。

就好像萌新三连说的那样：

啥百度啊？
百度啥啊？
咋百度啊？

最后再附带 combo 技：

大佬你到底会不会啊？

有的时候很多问题，
虽然我心里已经有一个大概率确定的答案，
但我也一样会问出来：

所谓活到老，学到老嘛（关谷语气）

100

对了，还有一点。
我称其为对高信息量有好感。

这点平常可能不会太在意，
但是简历/面试里面会很明显：
同样是讲三句话，
有些人就讲了很多有用信息，
有些人就像啥都没讲一样。

在《狼人杀》里面这点也会很明显，
很多高玩会频繁用“发金水”“警徽流”“丢水包”等新手听不太懂的词，
这会增加他的发言信息量，
让发言听起来更靠谱。
而很多说：“啊，今天死的是XXX，所以大概女巫XXX，希望XXX”的人，
都被“这货发言信息量真少”给放逐了。

这也是很多亚文化(meme)
好玩的地方。
同样的话语组成部分，
用独特的方式表达出来，
就会传达出微妙差异而信息量丰富的感觉。

假如我写代码的时候，
能写出表达精简，
边界完备，
“信息量很高”的代码。
那不需要队友在Code Review时喊666，
我自己已经一蹦三尺高，
开心地像见了新垣结衣一样了。

-1

其实边写还能边想到很多，
不过~~这本书边上的空白太小了写不下~~
我想去玩游戏了…

所以简单综述一下：

信奉万物皆科学
相信一定存在最优解
喜欢学习能力强的人
好奇心旺盛
对高信息量有好感

这大概就是，
我作为程序员的逻辑的一小部分吧。

消逝的此刻

Thu, 26 Oct 2017 17:48:42 +0000

前几天 Reddit 上有个赞的很多的
Shower Thought:

One of the most bittersweet feelings has to be
when you realise how much you’re going to miss a moment,

while you’re still living it.

我很喜欢这个说法。

跟女朋友聊到高中的时候，
她跟我讲过她有这么一种感觉：
“高三的时候因为学习压力重，
大家都很辛苦。
我虽然也很辛苦，
但我一点也没有不开心。
因为当时的我很清晰地知道：
这就是我的过一天少一天的高中生活了。”

真是一个很美妙，
又很轻小说的描述。
时间真奇妙。

五岁的某一天晚上，
我突然清楚了一件事情：
人类，是会死的。

在那之前，
我只是知识性地接受了这个事实，
但那天晚上，
仿佛有个打印机把这个事实印进了我心里。
巨大的恐惧包围了我。

随着时间的流逝，
那个夜晚在生命中也渐行渐远。
但随着我思考的越多，
死亡带来的孤独感就越重。

有几个坚固的事实矗立在我眼前：

我们微不足道。

我很喜欢 Fate系列动画作品的一个原因就是：
它把各个年代的英雄带来到了同一个时空里，
并且把他们的观念冲突展示出来。

有一次韦伯心情低落的时候，
亚历山大大帝指着世界地图笑着跟他说：
“你看，我当时征服的世界，
不过在地图上是这么一小块。
那在地图上，你有多大？我又有多大？
我们不过是世界的沧海一粟而已。”

时间总会前进。
即使我能改变人类，
那我也只能改变几十年的人类。

我们总会死。

那假如我能功在当代，利在千秋呢？
功在当代，利在千秋又与我何干。

《狮子王》里，
穆法沙带着小辛巴到草原上玩。
那天晚上夜空闪亮，
穆法沙就跟辛巴讲了一个故事：
“我们狮子族有一个传说，
就是我们每一个逝去的祖先，
都会化成天空中的一个星星。
每当你抬头看夜空，
发现星星在闪烁的时候，
那都是我们的祖先在看着你。”

在其它的传说、宗教、神话里，
总有类似的说法。

没办法改变命运，
我们只能改变自己的思想了。
真是愚蠢的人类啊喵。

我们只能自己思考。

小学时候看了很多《儿童文学》。
里面有一篇短篇小说我额外喜欢，
故事大纲是一个程序员创造了一个网游世界，
他爱上了里面虚拟的NPC，
结果最后他发现他也是被创造出来的NPC。

这个故事跟《楚门的世界》、《沙耶之歌》异曲同工，
就像以前BBS上流传的一句话：
“在网上，没人知道你是一只狗。”

难怪人类会在大刘的《乡村教师》里被评为5B级文明：

“上尉。你是个白痴吗？！”
舰队统帅大怒，
“你是想告诉我们，
一种没有记忆遗传，
相互间用声波进行信息交流，
并且是以令人难以置信的每秒1至10比特的速率进行交流的物种，
能创造出5B级文明？！
而且这种文明是在没有任何外部高级文明培植的情况下自动进化的？！”

“但，阁下，确实如此。”

“但在这种情况下，
这个物种根本不可能在每代之间积累和传递知识，
而这时文明进化所必须的！”

“他们有一种个体，
有一定数量，
分布于这个种群的各个角落，
这类个体充当两代生命体之间知识传递的媒介。”

“听起来像神话。”

“不，”
参议员说：
“在银河文明的太古时代，
确实有过这个概念，
但即使在那时也极其罕见，
除了我们这些星系文明进化史的专业研究者，
很少有人知道。”

“你是说那种在两代生命体之间传递知识的个体？”

“他们叫教师。”

存活到现在，
我可能有四分之一的空闲时间都在思考这类问题。
高一的时候跟物理老师也探讨过。
（高中物理老师是个老厉害的人，
十八岁前他就读完了大学，
三十多岁就教了二十多年物理了…）

不过当时的他也没办法说服我，
主要是几个问题过于终极：
“人类为什么要活着？
世界终究会毁灭的话，人类有意义吗？
即使我是特殊的人类，我能做出什么不同的事情吗？”

假如你能针对这几个问题，
给我你的回答的话，
那我知道有一家很好吃的蛋糕店，
我请你吃。

希望世界和平。
Carpe Diem.

怎么写Bug

Wed, 20 Sep 2017 19:49:38 +0000

时至今日，
笔者已经有十年以上的写Bug经验了。
是时候给各位想写Bug但还不够熟练的同学们，
分享一些写Bug的心得了。

概述

诚实地说，
写Bug本身并不是一件很光荣的事情。
但是写了一个很隐蔽/影响很大/看起来像是Feature的Bug，
然后再修复它，
就是一件伟大的事情了。
往往在你的行云流水般的bugfix代码下，
还能收获围观群众的666666惊呼。

总的来说，
写Bug的技巧可以分为下面几个维度：

开发功能
- 测试是懦夫的行为
- 不要让外界发现Bug
- Warning? 不存在的
- 复制别人的代码
- 遵循历史规律，不轻易改变
- 用中间状态完成功能
培养习惯
- 所有情况下都拥抱变化
- 配置个性化的开发环境
- 少做自动化的无用功
- 同时开展多个工作
- 信任他人的实现
- 永远充满自信
与人交流
- 永远只实现90%的方案
- 永远只实现100%的方案
- Code Review时也不解释自己的代码
- 为Bug的合理性辩护
- 适当指责别人写的不好
后期维护
- 当权责分明的人
- 信奉无知即无罪
- 分担权责到用户和运营上
- 多写代码，生产力=破坏力

下面就让笔者依次为你讲解具体的写Bug技巧。

开发功能

测试是懦夫的行为

Bug的天敌之一就是完善的测试，
为了写更多的Bug，
我们需要减少测试的量。
但是不写测试道义上说不过去，
所以我们要合理用一些话术来解释：

这个功能很简单，不用写测试。
这个功能太复杂，不想写测试。
这个功能是临时上的，不写测试了。
这个功能我们写不了测试。
放心吧，我写的代码稳得一笔，包准没有Bug。

更高级的做法是自己开发功能的时候，
先手动测试保证完善了。
但是几个月以后，
别人再改动相关代码的时候，
就神不知鬼不觉地写了几个Bug进去了。

不要让外界发现Bug

Bug是十分引人讨厌的，
基本上被发现了都会被修复。
那针对这个，
我们有两种操作可以做：

让Bug不被发现。
编码过程中，
多用catch Exception { ignore(); }这样的操作，
或者就把Bug的信息记到一个没人看的日志文件里面。
这样前一个操作做错了，
后面的操作还能接着做下去，
说不定就像小学数学题一样：
过程是错的，结果却是对的呢？
让Bug不被修复。
这个其实很简单，
只要我们写一个基于概率性假设的Feature就行了。
比如经典的race condition，
在高并发的情况下同时改某一个变量，
或者是npm的包不锁死版本，
然后不同时间依次部署在多个环境上…

Warning? 不存在的

代码里面有Warning是极其正常的事情，
我们只要保证代码能编译运行就行了。
IDE的大部分灰色/黄色/下划线都是一些强迫症程序员做的功能，
我们应当关掉IDE的这些警告。

还有Lint工具，
更多是用来检查拼写的。
每个人的代码习惯都不一样，
我们应当尊重个人差异，
只要有习惯不一致的地方，
就应当关掉Linter对应的检查。

多复制别人的代码

程序员业界有一句流传两百多年的俗话，叫：
“不要重复造轮子”。

所以我们应当多复制现成的代码，
这样一个Bug就会被复制成了两个。
而且以后新版本里，那部分代码的Bug被修复了，
但肯定没人会发现我们也复制了一份代码，
这里还有一个Bug。

当我们要定制化部分第三方依赖库里的代码时，
少用继承和组合，
多用复制和粘贴，
然后在我们需要的地方加上定制化的改动就行了。

遵循历史规律，不轻易改变

很多时候以前的代码写成这样是有原因的。
中国有句老话叫“萧规曹随”，
写程序里的意思就是“之前的代码就是这么实现的，我也应该要这么写”。

这样虽然我们只能在新的业务里引进新的Bug，
但是旧的业务的Bug我们可以继承过来呀。
而且把这一条技巧和上一条技巧结合起来就更佳了，
“复制以前的历史代码”，
是大大减少写Bug的工作量的一条捷径。

用中间状态完成功能

工作中写的代码大体上会分为技术代码和业务代码两部分。
业务代码很不好玩，
而且会有一个明确的deadline。

这个时候我们就要心中冥想“这个我要快点写完”，
口中默念“这个很容易实现”，
一边解释“先猥琐一点实现了，后面再整理一下”，
再依靠我们的编程素养三下五除二地解决问题。

虽然这样写出来的Bug生命周期不会太长，
但是万一后面大家都很忙，忘了这里有个中间状态，
那一些Bug的生命就会很长了！超棒！

培养习惯

所有情况下都拥抱变化

现代软件开发世界里有一个真理，
叫**“需求一直是变化的”**。
根据逻辑学来看：

因为需求一直是变化的，
又因为代码是要实现需求的，
所以代码也一直是变化的。

我们写出一个又一个新的Bug就有了坚实的理论基础。

而且这里还有一个酷炫小技巧就是，
最开始的系统设计一般都是简单的，
最开始的时间也是很充裕的，
但是往往变化的时间会比较急促。
所以只要我们大胆拥抱变化，承诺“这周内都能实现”，
这里就会有一个很小但充裕的时间让我们发挥，
写出一些别人根本设计不出来的Bug。

配置个性化的开发环境

开发环境永远，永远不要跟生产环境保持一致：
因为生产环境一般来说是Linux，Linux太无趣了。
我们应当用一些像Windows/MacOS这样不区分大小写的宽松的系统，
来当我们的开发环境。

用自己的电脑开发的时候，为了自己心情愉悦，
可以在全局装一些好看的字体、很好用的第三方库，
然后适当地在代码中引用这些定制化的很棒的工具。
同时测试时永远用最新版的软件，
比如浏览器、客户端、代码版本等。

当别人疑惑地报了个疑似Bug的问题时，
你可以自豪地回复：“我这是好的。”

少做自动化的无用功

假如一个自动化程序有Bug，
那这个Bug被修复以后就很难被重新引入。

但是假如我们每次做一些数据上的操作，
都直接调用代码，
或者是写一些一次性的脚本来“自动化”这个操作，
那我们每次都有机会引入全新的Bug。

虽然手动操作会耗费我们更多的时间，
但是它能带来更多Bug的可能性呀~

同时开展多个工作

厉害的人永远不会只在一个项目上留下他的Bug。

我们也要当这样的人，
所以就像“能力越强，责任越大”说的一样，
在同一时刻我们要敢于承担多个任务。
这里的任务可大可小，
但是每个任务都要是不同方面的，
假如不仅是紧急的任务，
还时不时会有利益相关的人来催一下就更好了。

这样我们在完成多个任务的时候，
还可以充分体验“上下文切换”的快感，
然后在多个项目上都留下了自己的印记。

信任他人的实现

正如小学、初中、高中每几年都要学一遍的《珍珠鸟》讲的那样：

信赖，往往创造出美好的境界。

作为单纯可爱的程序员，
我们也要信任他人。
信任用户这么聪明，肯定能看得懂报错，
信任产品经理给的需求，肯定简单，
信任设计师给的图，肯定容易实现；
信任前端传入的数据，肯定是合法的，
信任传入合法数据时，后端的接口肯定不会报错；
信任测试过的代码，上线了肯定没问题，
信任第三方的库，小版本肯定不会改兼容性，
信任这么贵的服务，效果肯定比MySQL好。

而且就算这种时候出了Bug，
我们也可以解释呀~
又不是我们的问题，
这个Bug，写的精妙吧。

永远充满自信，不用写注释

世界上20%的程序员，
写出了80%的程序Bug。
一般来说，看到这篇文章的程序员，
应该都是属于top 20%。

虽然说三年前的代码我不一定想的起来，
但是一年前的代码自己应该看得懂，
所以一般情况知道是自己维护的话，
就不用写多少注释了。

而且像我们这种英文很好的人，
写注释肯定是用英文的。
不过又担心看代码的人英文不一定好，
所以还是不写注释了。

基于自信的基础上，
我们还可以觉得所有自己写的Bug都是可以修复的，
所以一些暂时的Bug不用太重视，
所谓When there's a bug, there's a fix.

与人交流

永远只实现90%的方案

老程序员之间会口口相传的一句道理叫：
“相比于覆盖100%的复杂设计，我更喜欢覆盖90%的简单设计。”

虽然这样子写不出来100%的Bug了，
但其实根据这个原则，
我们可以把放弃掉的10%用户都看成是一个巨大Bug。

这么看起来，
我们在更少的工作量情况下，
完成了更大的Bug，
其实效率更高了呢。

永远实现100%的方案

中国的智慧长者们会讲一句东方谚语，叫：
“行百里者半九十。”

当我们做一个系统设计/业务实现时，
假如不能做到最好，
不考虑完所有的情况，
那其实相当于整个功能没有实现。

软件合理的流程应该是一开始设计好整个系统，
然后再开发，一次性全部上线，
之后再整理上一次的Bug，
伙同下一次的所有设计、功能再上线。
这样旧的Bug也可以活得更久，
新的Bug也可以持续上线。

在100%的方案里面，
Bug虽然会减少一部分，
但是我们可以分散写Bug的权责，
最终设计、实现、测试、上线整个流程的所有人都是Bug的父母。

Code Review时也不解释自己的代码

随着现代软件开发流程的普及，
大部分程序员用上了Git等版本控制工具。
但是这些只不过是上传代码的工具，
即使是版本控制跟项目流程工具结合时，
我们也应当相信个人的力量。

发Code Review时利用好自动发邮件功能，
少解释代码逻辑，多催别人“快approve我的代码”。
因为小的Code Review比较容易看，
写的Bug会被一眼看穿，
所以更棒的做法是发一次改动几百上千行的大的PR。
这样不仅能显示我们的工作量，
还能让别人对Review我们的代码望而生怯。

久而久之，
别人只能Review我们的代码风格，
然后Bug们就能隐藏在代码逻辑里，
在开发环境、测试环境、生产环境之间遨游了。

适当指责别人写的不好

假如以上的技巧你都掌握了的话，
那恭喜你，成为了一个写Bug中级工程师。
此时你不仅拥有了写Bug的权利，
你还拥有了指责别人的权利。

当然，我们不能上升到人身攻击，
所以我们应该主要攻击别人的代码：
“你这么写不好”
“我觉得这样写不行”
“你这么写以后会有Bug”

为了保持神秘，我们也要少跟别人解释为什么/什么是好代码什么是坏代码。
心态好的人被指责了，可能会去查谷歌，从而写更少的Bug；
心态不好的人被指责了，他可能会怀疑自己不适合干这一行。

总的来说，跟我们写Bug竞争的人会变少。
这样我们下次敞开写Bug的时候，
还能反驳“你也写了一个Bug”。

为Bug的合理性辩护

Bug也分很多种，
不同的场景会催生不同的Bug，
严重性、时效性、后果也各有不同。
写Bug的确是再正常不过的日常了。

根据“存在即合理”的说法，
我们要勇于为自己的Bug辩护，
主要的话术可以聚集以上的技巧，
总结精华如下：

怎么重现的？我电脑上是好的，你确定你操作没问题？
这种是边缘情况，不要这么操作就行，可以忽略。
以前就是这么实现的，这不是Bug，这是Feature。
最开始是好的，是改需求改挂的，假如需求不改就不会挂了。
跑脚本跑错了，改一下重跑就行。数据的问题，怎么能叫Bug呢？
这个功能不是我写的。
这个Code Review的时候，A君没有看出来。
这个测试的时候，B君没有测出来。

牢记以上话术，
适当时候抛出，
写Bug时心里的底气就会更足了。

后期维护

当权责分明的人

一个五千多年历史的文明古国里流传着这么一句话：
“不在其位，不谋其政。”

意思是“别人写的代码，我们不用管。别人写的Bug，我们不用修”。
现代工具提供了很便利的历史记录功能，
比如Git的话可以使用git blame，
这样的功能可以让我们快速定位某个Bug是谁写的。

平常跟别人讨论代码的时候，
多用“你的代码”、“我的代码”、“他的代码”等指代副词加强代码归属感，
这样出了Bug以后，别人是甩不了锅的。
虽然这样的操作弊端是我们自己写的Bug，
也得我们自己修复。
但是依照上文的操作，
我们肯定可以把锅给甩掉。

总而言之就是一句话：
Bug都是人写的，
不是你写的，就是我写的。

当权责分明的人，
这样别人就不会对我们的代码感兴趣，
我们自己的代码，
想写多少Bug就写多少Bug。

信奉无知即无罪

无知者究竟无罪还是有罪是吃瓜群众们很喜欢争论的话题，
但在我们写Bug的程序员业界，
很显然：无知者无罪。

比如我们要用一个第三方库，怎么用呢？
百度一下，找到的第一段代码复制粘贴下来就行了。
我们不一定要去理解所有的代码原理是什么的，
因为要实现功能的需求更紧迫嘛。
就算出Bug了怎么办？
无知者无罪，
我又不知道这样会有Bug。

不太清楚这里要怎么操作，
求A君写一段代码发我。
虽然我还是不太清楚具体操作，
但是这段代码是A君写的，
这样有Bug了有罪的也是他。
而且我之后调用出了问题，
也可以写出不少blame到他头上的Bug呢。

无知即无罪，就是：
我们写程序的时候，
不需要懂得每一行程序的原理，
能用就行了，
这样程序出问题了，
也怪不到我头上。
毕竟谁没个菜鸟的时候呢？

分担权责到用户和运营上

技术肯定是不能解决一切问题的，
而且技术肯定不能解决人的问题。

所以很多时候的Bug，
不是我们实现的不对，
而是用户的操作不对。

这个工具是写给程序员用的，
他们都很聪明，
就不用写那么完善了，
适当报个NullPointerException,
他们肯定能读懂trace，
报个segmentation fault,
他们肯定会用gdb逐步调试的吧。

这个工具最终是运营用的，
end user可以培训的，
所以就不用太好用了，
功能做出来就行。
适当报个400，
教一下用户用console看一下就行了。
不是所有情况的500都是用不了的bug，
有些情况只要那么操作就可以解决了。

用户怎么不懂呢？
这，也是另一种意义上的Bug吧。

多写代码，生产力=破坏力

好了，孙子兵法三十五计都看完了，
最后一步，那当然是提升生产力了。

只要你熟读本文，
掌握了Bug生产之术，
那你勤于加班，
多写代码
肯定能掌握Bug大生产之术。

就像中国神话里一位叫“愚公”的人说的，
写Bug也一样：

虽我之死，无子存焉；
但100行代码里有51个Bug，
修了1个，还有78个Bug；
虽码不加增，Bug无穷匮也。

还是要继续修炼也。

本文思想仿《如何写出无法维护的代码》

我眼中的大佬们

Sat, 16 Sep 2017 16:07:46 +0000

近期有一个表情“给大佬递茶”用的蛮多的，
我理解的“大佬”的含义，
就是“三人行，必有我师焉”里的“师”一样的含义。

最近因为在公众场合吹的牛逼多了，
有些不明真相的群众可能觉得我也是大佬。
我心有点惶恐，
于是打算给诸位介绍一下我眼中的大佬们。

DISCLAIMER:

本文没有客观事实，都是主观观点。
假如有不恰当的地方，那都是我观点不恰当。

这些大佬基本都是我认识他，但他不认识我，
没有利益相关。

Jeff Atwood, Stack Overflow 的创始人

在我刚开始补个人博客的有段时间里，
我~~单方面~~认识了很多大佬，
学习了非常多的博客文章，
Jeff Atwood (下称 Jeff) 的 codinghorror.com 就是其中之一。

他的 About Me 页面写的特别认真，
至少我很喜欢这种风格：
在单个页面内，
首先介绍自己，
再讲一些微不足道的经历，
最后主要讲自己的三观（世界/人生/价值）。

作为 SO founder,
Jeff 大概在业界也是知名的，
这方面我了解的不多。
不过他讲的几个事情我记得很牢：

一个是网站名称的由来，
就是《代码大全》 (Code Complete) 这本书里的小标题：
Coding Horror, 翻译成中文大概是“屎代码”的意思。
于是我也去补完了《代码大全》的中文版，
感觉虽然是有点年代的书，
但里面讲的一些程序员的劣习，
也是中枪无数。
于是看完了中文版以后，
我又很饥渴地把英文原版也学习了一遍。

还有一个就是写博客。
Jeff 曾多次讲到在他心目中，
写作是自我学习的很好的方式。
不过他自己写博客主要是想找个地方记一下好玩的事情。

陈皓，haoel, 酷壳的站长

陈皓（下称耗子叔）对自己的描述是：

大家好，我是陈皓，
我不是高手，我也不是牛人，
我只是在跟随着我的兴趣和喜好去学习一些技术。

不过在我眼中，
他是我认识的寥寥几个做编程技术十多年的人，
即使现在可能充当了CTO的角色，
但依然~~在写代码~~奋战在技术一线。

他的很多文章传播的比他的名字要广，
（换种说法就是被各大编程营销号转载过）
比如《程序员练级攻略》，
比如《“做环保的程序员，从不用百度开始”》，
耗子叔也会用很地道的语言汉化一些有趣的文章，
比如《如何写出无法维护的代码》

这些文章里总有一种很好闻的程序的味道，
我很喜欢。
能从这里那里学到一些一线工程师的很酷的想法，
也算是每天进步一点点了。

曹政，caoz

前阵子跟张总坐地铁聊天的时候，
我问他除了西乔霍炬，
还有啥很棒的公众号，求推荐一下。

他先是翻出了MacTalk, TinyFool, 嘀嗒嘀嗒等
商业互吹（此处褒义）的公众号小圈子推荐给我，
然后我们向往了一下这种大佬都是互相认识的氛围。
我又给他推荐了好像跟雷军、张小龙都很熟的keso。
最后他把珍藏多年的曹政（下称caoz）的公众号介绍了给我（公众号：caoz的梦呓），
张总介绍说他是4399的技术大牛，
大家都叫他曹总什么什么的。
当时我心里就简单地把caoz跟Fenng打上了一样的标签。

不过后来他发的好多篇公众号文章给我看改观了：
我发现caoz这个人，有意思。
比如他跟keso都会发文章搞事，
但他们不太一样。
keso喜欢怼大势，
就是xxx改变世界，
xxx不是好的方向，
格局很大，气势很足。
caoz喜欢怼具体的事情，
比如割韭菜 + 无数的举例，
而且也会表露出对具体的人的厌恶。

caoz这样更容易招黑，
~~粉丝也不容易涨~~
不过他也不care,
想说什么照样说，
而且还会故意说些“洗粉”的真话，
很是肆意。

排除一些我并不赞同的道理，
caoz讲的很多道理都句句到点，
有实际事情支持，
的确能学到不少。

//此处都是主观感受，缺少引用，因为找不到怎么生成微信文章的永久链接…

王垠，《完全用Linux工作》的作者

王垠（下称垠神），博客是当然我在扯淡 (https://www.yinwang.org/)
早年间一篇《完全用Linux工作》收获了很多迷弟，
后来的好几篇文章，比如《微软的秘密离职协议》也收获了很多黑子。
在我心目中，垠神是知乎三大话题性程序员之一
（还有一个是曾博（现已永久退出知乎））

撇去别的，垠神的本身经历使得他这个人充满了话题性。
首先是敢于表达刺耳的个人想法（并且多年没变），
光这一点并不是垠神过人之处，
垠神还会辩证地思考问题，
敢于在公众前表达对事物两面性的思考。
比如他最开始被大众所知是因为《完全用Linux工作》一文，
但是多年以后他又发了《谈Linux，Windows和Mac》一文。
又比如他最开始加入了微软，
然后又一个人地罢工（这样的事情的确不少）

大部分人眼中，垠神没有自己的作品，而且反复无常。
但其实垠神的文章，
把他对别人的意见那部分排除掉，
他对技术的理解、思考~~、运用~~其实是超越了大部分人的（比如我）。
比如他对 Kotlin - Checked Exception 的思考，
讲到程序设计和程序员能力的关系那部分，
非常有启发性。

而且很多时候，垠神的观点真的是振聋发聩，比如：

每次仇恨一个东西，你就失去了向它学习的机会。

以至于我司工作日的时候，
只要谁发现了垠神又发文章了，
他就会高呼：“垠神又发文章了！好特么勤快！链接我发群里了！”
然后大家纷纷一起学习。

其实我还蛮想把垠神跟凤姐放在一起类比的，
但是想想，知道凤姐但理解凤姐的人太少了。
这样容易引起误会，这一段就剪掉吧。

冰封，ice1000, 喜欢程序语言的高中生

我最开始是在知乎的女装话题下刷到冰封（下称ice1000）的动态的，
看了一圈发现这好像是个程序员友军，
又看了一下，发现是个高中生大佬。

跟上文讲到的几个大佬不一样，
ice1000 的影响力可能主要停留在知乎，
但 ice1000 的未来是无穷的。
虽说人人平等，但有的人更加平等，
很多道理早知道和晚知道是不一样的。

ice1000 能在高中的时候，
确定了自己的兴趣，并且打算为止奋斗一生，
比起我这种大学读完四年，
才确定我真的是喜欢代码的人肯定要强许多。
（更别提他 GitHub 的 activity 也是吊打我了）

祝 ice1000 能找到自己的道路，
认准它，顺利地走下去。

笛子，《你什么都没看见》《小绿与小蓝》系列作者

笛子Ocarina（下称笛子），
是跟孙渣，鱼总等画师一个圈内的画手。

看她的《你什么都没看见》，
我总感觉跟《疯狂怪医芙兰》有异曲同工之妙
（虽然画风非常不一样）
还有《小绿与小蓝》系列，
很多地方跟 xkcd 系列漫画也有异曲同工之妙，
或者说跟西乔的神秘的程序员系列漫画有异曲同工之妙。

虽然有“笛子，强，不上色”的梗，
但其实可以看出笛子就是一个很喜欢画漫画的人，
而且很幸运地，她的事业也是画漫画。
这个特性跟“奇思妙想”这个特性就产生了 1+1»2 的特性了。

最开始的《小绿和小蓝》就是笛子表达一些小思考的所在，
~~明明是笛子缺刀片了~~
里面的很多梗跟 xkcd 一样，
都是荒诞但有趣的：
比如“走钢丝时一边后空翻一边双手分别转5x5魔方同时倒背国家民法”的这种梗，
就跟“三人行，必有我师焉”是一样的道理呀。

最后，因为篇幅原因，很多大佬就不写上去了。
（我有一堆仰慕的大佬，但是这里的空间写不下了）

还有一些大佬，自身的姿势水平非常高，
但是因为比较少时间输出观点/价值观/干货/技术内容，
所以很容易被人民群众（比如我）忽略掉，
在此道个歉。

不论如何，
最后引用笛子的一篇感慨作为结束吧：

什么是连字 (ligature)

Wed, 13 Sep 2017 22:45:39 +0000

或者叫“为什么PDF里拷出来的有些字会消失”，
“为什么有些字体里fi可以连在一起”，
“Fira Code是怎么做到连体符号的”

ligature

ligature，维基百科中文页是叫“合字”，其实概念意义上更接近“连字”。
正如字面意义上，连字就是连在一起的字，比如中文的连字是这样的：

俗话说，见字如见人。

有的专家根据特总的签名，
分析说他的狂放就如同他那一横一样不羁……

在拉丁语系中，很多时候会用到连字这一特性。
比如说德语的字母 ß 最开始其实是 ss，
拉丁字母中的 W 最开始的时候是 VV, 两个 V…，
非常神奇。
而我们熟悉的音标里的 æ 这个字母，
看起来很像连字，但其实不是连字，
æ 是古英语等一系列语系里真实用到的字母。

fi与印刷体

在活字印刷盛行的时候，
人们都是用字模来印文章的。
一篇文章，
假如要用不同的字体，
那就要选用对应的不同的字模。

有些字体里面当字母f 和字母i 连在一起的时候，
f 的一横会跟 i 的一点撞上，导致不好排版。
所以为了方便、美观，有些字体直接会有 fi 连字的字模。
这里不论是印刷字体的连字，还是上面手写字体的连字，
都是一样的概念，都叫 ligature。

电脑字体里的 ligature

虽然说电脑字体不会有印刷字体所有的物理限制，
但有些字体的 fi 还依然保留了 ligature 的这一特性。
假如你在你的电脑字体配置页面找一找，
是可以找到相关的属性的。

基于电脑也能支持连字这个设定，
于是聪明的人就想到了可以用它来搞事！
比如有一款字体叫 Fira Code。

Fira Code 宣称自己是最适合程序员的编程语言，
因为它对各种数学符号都极度友好（细节请点开下图）

当然前提是编辑器也要能支持 ligature,
比如像 JetBrains系IDE:

果然正如古代智慧说的一样：

苟日新，日日新，又日新

还是要多学习一个呀。

数据仓库解决方案 RedShift 入坑指南

Fri, 08 Sep 2017 22:59:08 +0000

最近工程师小谢遇到了一个难题，
就是手头上有千万级别的数据，
但是没有一个快糙猛的解决方案。

提出问题

想直接看 RedShift 相关的，
请跳过前两节瞎扯淡。
直接到第三节观看。

不像少部分优秀的可以活在彼岸的人，
可以醉心于写出完美的数据库，
在须臾间学会所有的程序语言；
世上大部分程序员都活在此岸，
他们要解决一个个特定的业务问题。

工程师小谢就很烦恼，
上次产品经理小刘提了个老酷炫的IDEA：
“现金牛”。
观众们很过瘾，
但作为要实现功能的人，
小谢有点郁闷。

具体来说，难点在下面几个：

数据量很大。
公司是做菜品相关的，每天记录的菜品数据非常多。
而且随着公司业务发展，菜品增速增长率也很高。
（也就是“指数级上升”）
时间比较紧。
不像学校里的大作业，可以有一整个学期来实现到交付。
真正的需求是事情要尽可能早的完成，即使一开始不一定是完美的，
但是会更早得到外部反馈，正面/负面的评价有助于大家调整前进方向。
质量有要求。
基于“现金牛”的这个需求交付完成以后，又会有新的需求降临到小谢的肩上。
所以这个此时的解决方案，也要解决彼时的问题。
随着业务/数据量的增大，短时间内（比如说一年），解决方案得稳定靠谱。
长时间内（比如说三年），解决方案要能拓展，至少是便于重构的。

解决方案

上面的几个现世问题，
其实跟万千现世问题一样，
都是一个问题：如何在有限的资源下，完成既定的目标？
解决方案也都是通用的：转换资源、付出时间、更换目标。

当然，小谢明白，脱离实际例子的方法论都没有意义。
所以小谢打算整一个数据仓库 (Data Warehouse)

数据仓库，跟数据库 (DataBase) 很像，
就像军械库是放军械的地方，
车库是放车的地方，
数据仓库/数据库就是放数据的地方。
~~多了个仓是因为还放仓鼠~~

二者不同之处详细来说，
就是因为要解决的问题不一样：
数据库是要给业务提供基础保证，
数据仓库则是给面向决策的数据分析提供便利；
所以二者的设计思想也不一样：
数据库遵守范式设计，强调数据约束、一致性，读写操作都有涉及，
数据仓库则是存储大量冗余数据、统计数据，对读的优化更多。

举个栗子就是今天中午小谢去吃了四斤烤鱼（真能吃），
“四斤烤鱼”的数据存在了数据库里，是用来买单算钱的。
但“今天中午，四斤，烤鱼”这样的统计数据就存在了数据仓库里，
以用来之后的统计分析。

业界很多的数据仓库都是基于 Hadoop/Spark/Storm 的一套 Java 系技术栈的。
比如拼多多，用的就是 Hadoop/Hive/HBase/Kafka 一套技术栈。
比如小红书，用的也是 Hadoop/Hive/Spark/Kafka 一套技术栈。

但是问题来了：
这些小谢都不懂啊，很尴尬。
不过还好，小谢有钱，
他可以去招几个懂的。
很可惜，招聘是个玄学问题，
他看上的看不上他，
看上他的他看不上。

于是小谢想来想去，
也只能自己动手，
最终选择了：

RedShift, 亚马逊云服务全家桶之数据仓库管理助手

特点

作为一种数据仓库的解决方案，
RedShift 有几个特点：

省事，假如你也用了 AWS 的其它服务。
自带监控，需要定制化的话还可以跟 AWS CloudWatch 结合；
往里面插入数据推荐用的 COPY 命令是和 AWS S3 联动的；
高可用、拓展性、备份等都是 AWS 保证的。
提供全套 PostgreSQL 语法。
基本上兼容 PostgreSQL 的地方，换一下 DBDriver 就可以无痛使用了。
但是 RedShift 也只提供了一套 SQL 的标准，
假如要做 SQL 之外的（比如文件）数据存放，
就很吃力了。~~by design. wontfix~~
贵，相对而言。
定价大概最便宜的实例类型 (dc1.large, 15GB Mem, 0.16TB SSD) 是一年一万多人民币，
不算人力价格的话，比自建数据仓库肯定要贵。
不过算上人力价格的话……就另说了。

部署

部署使用 RedShift 的主要步骤如下：

先别急着创建实例，先按照 AWS 的教程走一遍，
会对 COPY/Encoding/Cluster 有初步了解。
~~不喜欢读英文文档的同学，可以右上角切换成中文~~
创建合适的 AWS RedShift 实例。
恭喜你完成了_从无到有搭建数据仓库_这个成就。
对接业务，比如选择合适的 Driver。
我们用的是 django, 直接用 psycopg2 就可以连接了。
然后就是ETL、缓存、图表等通用的业务操作了。

心得

用了 RedShift 一阵子，
有几点学到的地方：

SQL 语句不是直接执行，而是编译后分发执行。

不论我们执行任何语句，即使是 INSERT INTO 这种单条操作，
RedShift 都要编译后执行，耗时 500ms 起步_所以要用COPY来做数据导入_。
又比如我们部署了四个 RedShift 节点，那在
SELECT * FROM orders WHERE business_id = 100 编译完成以后，
RedShift 会把操作根据建表时选定的分区键 DISTKEY 把命令分发到各个节点操作。
所以合理的表结构也是查询速度的关键_通用的废话真理_。

插入数据用 COPY 命令；更新数据 COPY 到临时表以后，用 DELETE USING + INSERT INTO 来更新数据

因为每条 SQL 都要编译，所以尽量做批量操作，单条操作是非常愚蠢的。
（就像我们最开始那么愚蠢一样=_=）
RedShift COPY 命令支持 GZIP, JSON, From S3 等多种操作，
大部分情况下，加载速度和存储效率都会比普通的 INSERT 要好。
同理，更新单条数据采用了先删再增的方式。

定时维护数据仓库

RedShift 不会自动回收 DELETE/UPDATE 所释放的空间，
需要用户手动运行 VACUUM 命令来清理表。
VACUUM 本身也是IO密集型操作，
所以最好是在空闲的时间（比如早上四点）定时跑。

注意表的限制

在 RedShift 里，
unique / primary key / foreign key都是展示信息，
没有实质约束力。

还有 RedShift.varchar 存储的是单字节字符，
像 MySQL 的 utf8 默认是三字节字符，
假如用了 utf8mb4 就是四字节字符。
所以 MySQL 里的 varchar(50) 换算到 RedShift 里就应该是 varchar(200)。
被Emoji坑了的人留

总结

总的来说，
RedShift 的最大的好处在于用钱换取生产力，
简单易用，是 AWS 全家桶用户对数据仓库的一种解决方案。
具体用法多加注意，也没有什么特别之处。

不过最近好像是给亚马逊交了不少钱，
他们都派工程师上门免费 support 了。

小谢心想。

课外阅读

写代码怎么偷懒？多练练

Thu, 31 Aug 2017 20:25:12 +0000

相比于“一门语言”，
“一门程序语言”更多时候是“一门规范”。
（当然，“语言”本身就是“规范”。）

上次讲到了写代码想偷懒的话，
搞明白、想清楚再写是解决根源的一个办法。
但是凡人（没打错字）的需求始终不是重点，
写程序要偷懒，
最终还是在代码上偷懒的。

Best Practice

外国程序员很喜欢念叨一个词，
叫Best Practice。
比如说Java里面JSON要怎么处理，
就可以搜Java JSON Best Practice；
比如我对数据库一窍不通，
但我就是要学，
可以搜Database Best Practice；
比如我是甲方，
我不知道我自己想要什么，
我也可以搜Requirements Best Practice。

这种英文单词一般会有一个直译的中文，
叫最佳实践，
听起来巨蠢。
但是用来举例子就很好用。

我加入再惠的时候，
只写过一点Python，
代码习惯也是不加encoding，
不知道from __future__，
写print不写括号的，
所有要用到的第三方库都装在全局的site-packages下面。
来了以后我知道了virtualenv。
后来张总玩Lucene的时候我给他配了下Gradle，
并解释了一下：“这个东西很简单的，跟virtualenv是类似的概念。”
张总感慨道：
“其实学一门语言就是从这些工具开始啊，
这样才有一种我上手了的感觉啊！”

还有就像Go语言的gofmt命令，
这个命令会强制执行统一的代码风格调整，
不能配置、不能定制化、缩进统一使用Tab。
我十分痛苦，
不过也十分认可这里的思想：
“语言风格就是~~林黛玉~~哈姆雷特，千人千面。
相比于完美的风格，统一的风格更科学。”

Best Practice就是实际操作时的指南，
了解、掌握、实践Best Practice可以~~少些很多代码~~少走很多弯路，
用精妙的方法解决实际问题。

精妙的方法

按照套路，接下来应该讲一段精妙的方法。
不过小弟我没啥精妙的方法，
就只能举自身当反例了。

在写API的时候，
经常要处理URL，
处理URL实际上是字符串拼接。
比如Python里面把一个dict转换成query string格式，
我以前会这么写：

params = {'name': 'afu', 'action': 'take a plane'}
query_string = '&'.join(['{}={}'.format(k, v) for k, v in params.items()]) # 'name=afu&action=take a plane'

当时自我感觉良好，
觉得Python不愧是Python啊，
List Comprehension真优雅，真好看。
然而这段代码不仅有Bug，
其实Python有专门的库urllib来处理这类问题，
urllib也已经考虑了各种边界情况（比如带非法字符等）：

# 举Python3为例
import urllib

params = {'name': 'afu', 'action': 'take a plane'}
query_string = urllib.parse.urlencode(params) # 'name=afu&action=take+a+plane'

后来又学到了urlencode函数在Python2和Python3的位置都不一样，
一般是用six这个库去处理兼容性的。
下面这段代码就不需要额外说明_举Python3为例_了：

import six

params = {'name': 'afu', 'action': 'take a plane'}
query_string = six.moves.urllib.parse.urlencode(params) # 'name=afu&action=take+a+plane'

虽然有很多种方法都能达到同样的效果，
但软件工程中，
大家往往都定下一个Best Practice然后遵守它。
这样不仅能省下写程序的功夫，
也能省下沟通争辩的功夫。
就像Zen of Python里说的一样：
There should be one-- and preferably only one --obvious way to do it.

之前我一直很好奇大部分人在用Python写datetime类型的时候，
都是用import datetime+datetime.datetime(), datetime.date()的写法，
我就一直不解，
from datetime import datetime, date+datetime(), date()这样感觉更好啊？
而且后续的代码更短。

后来读到Kenneth Reitz的Hitchhiker's Guide to Python的时候我才明白，
Explicit is better than implicit的体现就是显式指定包名，
这样代码表现力就会更强，也更易读。

## Very bad
[...]
from modu import *
[...]
x = sqrt(4) # Is sqrt part of modu? A builtin? Defined above?
## Better
from modu import sqrt
[...]
x = sqrt(4) # sqrt may be part of modu, if not redefined in between
## Best
import modu
[...]
x = modu.sqrt(4) # sqrt is visibly part of modu's namespace

从学到这一点以后，
我就下定决心再也不用from datetime import datetime了。

总结

Best Practice这种东西，
看起来很美好，
用好了可以大大偷懒减少工作量。
但它有一个重要特性：
Best Practice从来不是试出来的，
而是思索、学习、择优得到的。
多加一个if，多加一个机器，多招一个人，多加一点班
可能只能解决当下的问题。
平时多学习一个，
才能到了要解决问题的时候，
面临技术、业务、上线时间的多重压力，
优雅地使用Best Practice解决问题。

总的来说，
为了偷懒 ~~少干活~~提高效率，
我们又定下了这么些小目标：

多学习一个Best Practice
学到了就用，能用精妙的方法就不用愚蠢的方法
通过思考来学习，而不是完全通过试错反馈机制来学习

毕竟编程风格可不能是散弹枪编程呀。

写代码怎么偷懒？我想想

Wed, 30 Aug 2017 23:10:52 +0000

我真的不是因为写了Python，就在黑Perl。

起

最近装了 wakatime 这个控件以后，
我一直忍不住好奇心去看看我平常到底有多少时间在写代码。
经过严谨的数据统计表明：
我只有25%的时间在写代码。
（按一周40小时算，
我一周只写10小时的代码=_,=）

这样不好。
于是我决定奋发图强，
在自以为沉浸地写了一周代码以后，
25%变成了33%。
于是严谨的数据统计依然表明：
我大部分的时间都在划水。

于是我放弃了挣扎，
就像苏轼朋友佛印和尚讲过的一样：
既来之，则安之 不是他说的

我很开心地想道：
“哎呀。
我就花这么一点点时间干活，
是不是说明我效率高呀？”

“不是的，只不过是因为你懒而已。”
心里的正义小人蹦了出来。

我十分开心地嘴硬道：
“对呀对呀，我就是懒。
而且就像我以前说的，
懒有那种没有建设性的懒，
还有那种一劳永逸的懒。”

嗯，今天我就要尝试说服我心里的正义小人，
我不是在偷懒，我是在想问题！

按老规矩，
用讲故事的方式讲道理。
献丑了！

承

我从大四到毕业，
一直在QAD当研发（就是研发工程师）
一般来说，“研发工程师”这个说法是分工上这么叫的，
洋文里叫 SE, Software Engineer,
对应测试工程师 QA, Quality Assurance。
互联网公司里是Web编程的话，
会从另一个维度上分成前端工程师 FE, Front End,
后端工程师 BE, Back End。
有些也会从部门上拆分成架构、技术（业务）、算法、数据不同的组。

QAD主要是按业务拆分研发部门，
我们当时是Foundation组（基础架构组）。
公司做的是SaaS形式的ERP系统。（SAP, Oracle都是我们的竞争对手）
这里的SaaS可以简单理解为年费会员，
大众(Volkswagen)公司买QAD的ERP系统并不是一锤子买卖，
当合同签订以后，
我们还要负责整套系统的安装、培训、维护、升级工作。
（当然大众也要对应地交“物业费”就是了）
公司部门分工大概如下：

R&D 负责开发软件。R&D也就是研发部门，Research and Development, 我在这…
Sales 负责销售产品。（有的时候研发还没做完，产品就卖出去了，于是倒催研发…十分神奇…
Service 负责产品的安装、上线、培训。有的时候客户有一些定制化的需求，Service也是要写代码的。比如中国的医药公司要开发一套药监局审查流程，这个明显不是标准流程，就需要定制化开发。
Support 负责日常的支持。比如产品平时出Bug了，晚上出Bug了，周末出Bug了，都要负责给客户解决…
Finance, Law, HR, CEO 等其他队友提供内部支持，维系组织有序运转。

我当时参与的项目是叫CVC, Customer Version Control。
要解决的问题，就是定制化开发中的，代码版本控制难题。
比如还是大众公司，
他们2008年就安装了QAD2008版本，
然后基于2008版本做了大量关于车辆测试、车辆安全性能等方面的定制化开发。
于是在QAD要升级主程序版本的时候，
大众公司惊呼：“1079 Merge Conflicts Found!!!”
这种定制化和主干的冲突，
只是当时我们要解决的其中一个问题，
其它还包括有超过10G的代码本地环境构建，
dev-test-sup-prod多环境代码管理，
soft/hard lock等。

转

正义小人：“ok，于是你讲了这么多，
跟具体写程序相关的一句话没讲……”

的确，具体写程序的话是一句没讲。
那既然都扯这么多了，
我就再扯多点吧…

技术选型上，最开始用了 Git + Perl。
因为要做代码版本控制，
所以核心的轮子就用了Git，
当时团队的技术栈主要是Git vs SVN，
又因为要做多环境管理，
所以git rebase, git cherry-pick, git filter-branch等一串能修改历史的命令就优势明显。
又因为整个项目最终是一个命令行工具，
而且团队之前的主要技术栈是Perl，
项目语言就采用了Perl。
Perl这门语言最强大是它的命令行交互和文本处理，
很多shell命令是天生共通的，
比如echo, test -f, $@等；
文本处理上，正则和一些heredoc也是非常美妙。
而Perl最大的问题倒不在语言本身被诟病的鬼画符上，
最大的问题是：Perl日渐衰弱。
比如假如我们说我们招Java工程师，
那其实可以招到很多人才，
但同样招Perl工程师，
招到同样人才的概率也不一定会高很多，
但是付出的成本要高更多。

于是后来我干了一件事情，
下班时间用Java把CVC给重写了。
三四月份的上海特别凉快，
我住的离公司也近，
六点多吃完饭，走路回家洗个澡，
穿个拖鞋就蹦跶回公司。
白天写Perl，晚上写Java，特别开心。
当时老大也特别会顺势而为，
他看我自己在重构项目，
分给我的活也更少了，
于是后来上班的时间我也在“划水”写Java了。
因为需求明确，功能点清晰，
就这样过了两个月，
两万行的Perl代码再加同样量级的单元测试，
（一时间竟没找到比代码行数更恰当的数据……）
被我重构了一半到Java…
后来大家一起把各种Edge Case补上了，
整个产品正式切换成了Java，
也算是一点微小的贡献吧。

合

我在QAD的时间(2014年7月到2016年10月)
基本上都贡献给了CVC这个项目。
同样的功能，
Perl版本用了一年多实现，
Java版本用了几个月就实现了。
决定性因素跟语言表现力毫无关系，
而在于业务需求和业务理解上。

正如上文介绍项目流程里讲的，
项目要做的是定制化开发，
需求就是来自于Service部门同事。
他们一开始是不知道什么样的软件是好用的，
我们定义好的产品模式（比如自由checkout文件），
但是他们觉得另一种模式更好（开发人员更换频繁，需要对文件加soft lock），
或者是觉得产品可以更好（比如流程要和Jira高度结合）。
所以其实我们在Design - Refine这个流程上不断进步
（中文的说法叫“走了不少弯路”）

还有我们在重构过程中，
因为知道了整体的需求的样子，
就能更好地抽象逻辑。
就像是建筑师设计房子的时候，
因为知道了整体架构，
他才能确定房梁的承重，
部件的用材。

正义小人想了想，说：
“噢，我明白了。你的意思是说，
偷懒不写程序，其实只是停笔，
想想要写什么样的程序？
需求更准确，理解更清晰，事情才会更好做？”

“对呀对呀！满分理解！”

正义小人又一脸嫌弃：
“但是现实生活中，是不会有这样的情况的。”

是呀，所以我也只能一边说着“学到了学到了”，
一边想着“我是谁，我在哪，我要写什么程序？”

HR与程序员的日常（二）：OKR是啥

Sun, 13 Aug 2017 22:17:55 +0000

TI 输了，
熬夜看比赛的 Lirian 感觉心很痛。
于是他打算换个心情，
看看 Mia 最近的学习任务是啥。

OKR 是什么

Mia 最近听的课程刚好讲到了 OKR 。
Lirian 其实只知道 OKR 是
Objectives and Key Results 的简称，
是一种绩效考核的方式，
KPI 是另一种绩效考核的方式。
感觉 OKR 跟 KPI 的关系，
可能像是素质教育与应试教育的关系一样，
各有优势，各有不同。

于是 Lirian 用一招抛砖引玉打开了话题：
“话说 OKR 和 KPI 究竟有啥区别啊？”

Mia 回以一招斗转星移：
“我觉得 OKR 和 KPI 是有本质区别的。”

Lirian 顺势一招乌鸦坐飞机问了下去：
“噢，有什么区别~请讲~”

没想到 Mia 不坐飞机，一招借力打力回了过来：
“那我先问你，你知道 KPI 是什么吗？”

Lirian 顿时懵逼了：
“啊…不知道……大概是绩效考核的一种方式？”

“你这么讲也对。
KPI 的全称其实是 Key Performance Indicator,
翻译成中文就是 关键绩效指标。
工作上，每个人都可以有自己的 KPI,
一般是一年/半年结一次，
这个目标要符合 SMART 原则。”

“啥是 SMART 原则啊？”

“SMART 原则就跟你知道的 SWOT 分析方法一样，
是外国人很喜欢的缩写 (acronym).
具体来说，就是
Specific, 具体的,
Measurable, 可量化的,
Achievable, 能做到的,
Realistic, 现实的,
Timely, 有时限的
这五个形容词的英文首字母缩写。
一个科学的 KPI 就得 SMART.”

“噢噢噢，明白了。
比如诸葛亮的 KPI,
今年之内平复南蛮，
就比有生之年光复汉室要科学得多？”

Mia 勉强赞同了这个类比：
“呃，可以这么说吧。”

为什么要用 OKR

Lirian 想起了最开始的话题：
“那，OKR 和 KPI 究竟有啥本质区别呢？
我感觉 OKR 也得 SMART 吧……”

Mia 想了想，说：
“我觉得，KPI 和 OKR 的目的是不一样的。
KPI 是告诉你 要我做什么，
OKR 是告诉你 我要做什么。
还有，KPI 一般都和奖金挂钩，
OKR 就可能不会和奖金挂钩。
KPI 可能是一下子定一年的目标，
OKR 经常会变…”

Lirian 感觉信息密度一下子变大了，
赶快打断了 Mia 的吟唱：
“且慢，小弟听不太懂……
什么是 要我做什么 ?”

“KPI 的 要我做什么 指的是它一般都是从上到下分解的任务。
比如我们公司今年要朝市值一亿元去努力，
每个部门要怎么怎么样，
具体到每个人要怎么怎么样，
这些都是要定性定量完成的任务。
而 OKR 的 我要做什么 更多是把一亿元这个目标给摆出来，
然后部门去决定，短期、长期的部门目标。
每个人也会根据部门的目标，
去决定自己的目标。”

“啊？这么听起来 KPI 考核压力很大啊！
听下来我还是喜欢 OKR …”

“是的呀，OKR 就是硅谷湾区那边弄出来的，
Google 就把 OKR 给发扬光大了。
不过其实这个会因人、岗位而异的。”

“嗯，怎么讲？”

“KPI 里面有一点很重要，就是可以量化。
比如像计件工作的车间工人，
可以直接用完成数量来考核。
这种时候他的个人意愿、创造力等不会是考核里的重要因素。
但像不能量化的工作，
就像你们程序员，
难道能用代码行数来考核吗？
明显不科学。
此处有想到了 K&R naming convention 而死命点头的 Lirian
像 HR,
假如是做招聘还好，
可以根据招聘岗位数量来量化。
但是假如是做培训什么的，
也无法量化，强行上 KPI 就会很痛苦。
所以说 KPI 和 OKR 这两种绩效考核的方式，
是因人、岗位、公司而异的。”

此处 Lirian 又想到了《主角与配角》里的陈佩斯

朱时茂对他说：“像你这种人，还真得下死命令。”

明显就是 OKR 和 KPI 的戏剧冲突啊。

Lirian 思索 + 理解了一番，
又问：
“那像 QAD 呢？
QAD 是用 KPI 还是 OKR 的？”

QAD 是 Mia 和 Lirian 相识的地方。
一家专做 ERP 的跨国软件公司，
主要对手是 SAP.

Mia 邪魅一笑：
“QAD 既不用 KPI,
也不用 OKR.
QAD 用的是 MBO.”

Lirian 惊了个呆：
“还有这种操作啊？
听起来像是啥电视台的名字，
这个 MBO 又是什么？”

Mia 解释了一下：
“这个 MBO 呢，
全称叫 Management by objectives.
中文可能叫 目标管理，其实跟 KPI 有相似之处。
它是上世纪六七十年代出现的绩效考核方法，
比 KPI 和 OKR 都早，
萧规曹随，QAD 就一直用 MBO 用了下来。
不过近两年转的 PDP,
其实就有 OKR 的影子。”

OKR 要怎么操作

Lirian 想了想，
又理了一下思路：
“既然 OKR 和 KPI 是因部门而异的，
是不是意味着公司里可以同时使用两套绩效考核的方式啊？”

“是的呀。
就像邓爷爷说的，
不管黑猫白猫，抓到老鼠的就是好猫。
所有管理理论在具体落地的时候，
只要合适就可以实施。”

“那，有没有可能同一个部门里，
有些员工用 OKR,
有些员工用 KPI 管理呢？”

“哦，这个不可能。”

Lirian 表示疑惑：
“为啥呀，
假如我在一个 OKR 团队里，
但是我就是需要明确的量化的指标告诉我干啥，
那该咋办？”

Mia 回答的很快：
“那其实说明你不适合这个团队，
因为团队有自己的统一风格也是很重要的。”

Lirian 只能无奈地学到了这个事实：
“好吧……”

讲到了团队，Mia 又补充了几点：
“目前的 OKR 应用状况是：
在中国，用的比较多的是创业公司、互联网公司、正在转型的公司。
美国的话就是硅谷的科技公司。
当然因为 OKR 其实只是一个指导方针，
所以每个公司执行的政策也会各有不同。”

Lirian 心想：
嗯，正如每个人都会有一套 RestFul 的风格……

Mia 又想起来 KPI 有一点很大的弊端：
“还有就是 KPI 有一个很大的问题，
大家很容易本末倒置。
为了完成 KPI 的定量指标，
就背离了公司本来的目标。”

“是啊，不忘初心很重要。
希望 CN Dota 加油，
明年 TI 加油吧。”

“啊？”

“唔，我来跟你讲讲什么是 TI 吧。”

（本章完）

GitHub上的小标签有什么好玩的

Tue, 08 Aug 2017 23:10:01 +0000

GitHub很多项目主页都会放上好玩的小标签（GitHub Badges），
这次我们也来玩点表面功夫。

首先，我们要有一个项目

前阵子靖哥哥口嫌体正直地吐槽了一下lowdb：

这个lowdb，
好用是好用，
但是也太low了吧…

我十分好奇，
跑去看了看lowdb的介绍：

这是一个 JSON 格式的微型数据库。

诶，微型诶，感觉萌萌哒。
那 Python 有没有对标的库呢？
有，那就是tinydb~

tinydb 大概只有1200行源代码，以及1000行测试。

啥？！这还tiny呢？
怕是18级的tiny吧？

于是我们决定，
要有一个比tinydb还tiny的，比lowdb还要low的数据库。

起名字顿时是个问题。
既然犹豫不定，
那就选择原谅他吧~
于是又一个轮子诞生了：

原谅数据库(hui-z/ForgiveDB)

GitHub Badges

忽略README里对项目本身的吹捧，
Logo下面那一长串绿绿的小标签，
就是Badges啦~
由于程序员一般都在GitHub上活动，
所以大家也习惯把这些叫做是GitHub Badges
（即使在别的地方也可以用到它们）

本质上这些小标签就是能点的图片，
比如用 Markdown 语法可以这么写：

[![ForgiveDB](https://img.shields.io/badge/ForgiveDB-HuiZ-brightgreen.svg)](https://github.com/hui-z/ForgiveDB)

*这么一长串实际上是 Markdown 里图片的语法，加超链接的语法组合成的*

![图片的语法](https://img.shields.io/badge/ForgiveDB-HuiZ-brightgreen.svg)

[超链接的语法](https://github.com/hui-z/ForgiveDB)

上面一串就会变成这样子：

这么一长串实际上是 Markdown 里图片的语法，加超链接的语法组合成的

超链接的语法

各种 Badges

具体来看，
我们在 ForgiveDB 里用到的标签有这些：

shields.io.
这个值得单独拎出来讲，
因为他们是个专门做 Badges 的网站，
上面图还是 SVG 矢量图，
在任何分辨率屏幕下都不会模糊。
假如我们想挑各种各样奇怪的 Badges,
（比如 star 项目的数量、
issue 关闭的数量、
npm, pypi, nuget的版本、
甚至是自定义任意字符）
都可以上shields.io找找看。
PyPI.
这个是 Python 官方的包仓库，
shields.io也支持版本自动嗅探。
低于 1.0.0 版本的好像还会变成屎黄色…
pyup.io.
这个服务很好玩，
授权以后它会自动检测你的 requirements 是不是最新的。
假如一有更新，
pyup-bot 会直接给项目提一个 Pull Request…
简直酷炫。
travis-ci.org.
这个就是大众熟知的 Travis 自动化集成工具了，
Travis 对开源项目免费，
十分友好。
而且功能强大，
和 GitHub 也有很多集成，
用着十分舒服。
（前提是你得写点 UT 什么的）
其它：
还有一些 CodeCov 测试覆盖率,
AppVeyor 又一个好用的 CI,
CircleCI 双一个好用的 CI
等等，等等……

大概这就是给 ForgiveDB 挑好看的标签的旅程了。
这份心情，
就像是给心爱的键盘选好看的键帽一样美好。

最后欢迎大家给 ForgiveDB 提 Pull Request~
就算是像靖哥哥一样只改改文档，
混个 contributor 也行啊~

我们是怎么升级到Python3的

Sun, 06 Aug 2017 12:07:32 +0000

最近我们从Python2.7,
全线升级到了Python3.5。

Python2 和 Python3 有啥区别啊？

在程序员的理想乡里，
程序语言理应只是个好用的工具。
然而在现实生活里，
程序语言甚至是程序语言的版本，
关系到工程的很多方面。
Python2和Python3就像是小黄车和摩拜一样，
在某几个大的特性上有区别，
但本质上都一样，
不过一些细微之处又有不同。

比如说 Python2 最坑的 Unicode.
写过 Python2 的人总会遇到 UnicodeDecodeError 和 UnicodeEncodeError 这样的错。
在电话面试的时候，
我们回答候选人我们为什么会用 Python2,
也是把锅丢给谢老板：

嗯是这样的，
我们第一行代码到整个初期框架都是 CEO 选的。
他是美国回来的，
所以不知道中国要用中文，
也会遇到 Unicode 相关的问题。
于是他没想太多，
就选了 Python2.7.

真实原因还有很大一部分是因为当时一些库对 Python2 支持比较好

除了 Unicode 的区别，
Python2 到 Python3 还有一些系统自带函数有变化。
比如 urllib.urlencode -> urllib.parse.urlencode,
StringIO.StringIO -> io.BytesIO。
一般项目里面可以用six这个库来做兼容，
比如上面举的两个例子可以用six.moves.urllib.parse.urlencode
和six.BytesIO来替换，
Django也自带了一个six在django.utils.six.
不过我们是自己搭建环境，
所以其实不用考虑兼容性，
迁移工作大概的 Milestone 如下：

一些微小的工作

确保自己代码的兼容性。
确保第三方库的兼容性。
确保单元测试能过。
确保测试环境、集成测试能过。
正式环境切换 Python3！
宣布辉煌结果！

比如说讲些我们具体做的事情吧：

柳老板很早就想把~~谢老板的~~Python2换了。
所以大概在16年底的时候，
我们都有这个心理预期。
因为我们都是 PyCharm 用户，
(JetBrains 家巨好用的 IDE)
所以都打开了 Python Compatibility Inspection。
然后写代码的时候注意不使用xrange(), dict.iteritems(), print ,
而用range(), dict.items(), print()来代替。
对于Unicode一类的问题，
我们使用了__future__这个功能，
确保每个文件的头都是：

# -*- coding: utf-8 -*-
from __future__ import absolute_import, unicode_literals

# 第一行指定 encoding
# 第二行 absolute_import 指定优先从绝对路径 import
# 参见 PEP-0328: https://www.python.org/dev/peps/pep-0328
# 第二行 unicode_literals 指定字符串默认使用 unicode 类型
# 参见 PEP-3112: https://www.python.org/dev/peps/pep-3112

比如有个很蠢的py2to3的工具，
用它最好情况也只能把上面说到的“自己代码和系统依赖”给替换了。
具体的库替换、正确性验证还是得自己做。

后来我们又大概过了一遍用到的第三方库（requirements.txt）。
最大的依赖 Django 本身是2/3都兼容的，
然后像 celery/redis/requests 这种兼容性也妥妥的。
之前我们用的 AWS Python SDK - boto 不支持 Python3，
这个好说，对应的功能可以用boto3来替换。

比较麻烦的是当时用的微信库python-wechat-sdk。
这个主要是我们用到了微信的很多功能：
消息回复、用户管理、模板/图文、各种素材等。
本身代码量就不小，
而且之前的代码写的还比较屎，
亟需重构。
于是我们花了几个月来重构代码+换库，
最终换成了更科学更好用的wechatpy。

代码上的准备工作做完以后
（虽然这是轻巧的一句话，
但是因为实际开发中，
不可能空出一段时间专门用于架构升级。
所以我们都是在各种业务需求中找夹缝做的，
大概用了半年。）

代码上的准备工作做完以后，
我们又用Python3跑了一下单元测试(UT)。
完善的自动测试，是平时的保障，是关键时刻的定心丸。
理论上 Python2 到 Python3,
不应当有任何外部表现差异，
UT也不应当有错。
所以在修复了UT的错误以后，
我们就有信心切换 Python3 跑跑了。

这里还有个小差别，
就是我们之前的服务器用的是 Ubuntu 14 (Trusty)，
Ubuntu14 上默认的 Python3 是 Python3.4。
最新的 Ubuntu 版本是 Ubuntu 16 (Xenial)，
上面默认的 Python3 是 Python3.5。
柳老板也心水了 Ubuntu16 很久了，
于是这次切换 Python3,
我们也顺便把服务器版本升到了 Ubuntu16。
~~不能print中文的feature也下掉了~~

然后就是测试环境切换 Python3，
生产环境切换 Python3 了。
这里也有个小插曲，
生产环境切换 Python3 的时候，
我们原本想着先只升级一部分Server（灰度），
但是 Celery 的 Python2 Producer抛出的任务，
Python3 Consumer能接，
但是百分百完不成…

于是我们决定这还灰个蛋，不灰了！
找一天晚上点份奶茶和小龙虾，
全线切换Python3！
因为做好了前期准备，
所以我们大概只花了十分钟切换成了Python3~
腰也不酸了，
颈椎也不疼了，
连美餐的饭也好像变得美味了起来。
现在的我司后台就是跑在Python3上的~

最后还有就是大家的开发环境也切换一下 Python3 啦，
以前写的 docstring 可以切换成 type hintings 啦之类的微小的工作了。

# Python 2 的时候这么写
def old_hint(messages, data=()):
 """
 :type messages: list
 :type data: list[dict]
 :rtype: str
 """
 pass


# Python 3 就可以这么写
def new_hint(messages: list, data: list(dict) = ()) -> str:
 pass

总结

从 Python 2 到 Python 3 的好处见仁见智，
对于不同的情况各有不同。
做成这么一件微小的事情，
感受比较深的就是：

目标要清晰。
比如我们早早地就把 Python 3 提到了我们的 Scrum Board 上。
除了技术很清楚我们要做什么，
产品也会有意识地给我们升级架构留下排期。
目标清晰，大家步伐就会一致。
要有推动者。
比如柳老板就充当了整件事情的推动者，
有序给大家分锅，具体哪个模块谁来重构，哪个库谁来换。
一些没人想干的麻烦/要背锅的事情他也都做了，
比如去修UT的兼容性之类的…
互相信任真好。
后端升级架构，
其实各方面都会受影响，
比如上文提到的 Celery 那个坑就让我们紧急回退了版本，
或者类比一下游戏厂商每周例行的停服务器操作。
这时候产生的一些锅，
就被一线的队友背了，
他们也没多埋怨就帮我们擦屁股去了…
ORZ 感恩！

不论如何，Python 3毕竟是趋势，
Django的新版本不会支持Python 2,
Celery的新版本也不会支持Python 2了。
我们也不能落后呀。

就像陈皓老师常说的一样：

技术债是还不完的，但我们也要一直还！

~~陈皓老师：不，我没说过这句话，你自己编的。~~

人类真愚蠢——《南方公园》

Sat, 05 Aug 2017 19:29:14 +0000

给你们介绍一个美漫。

讲到美国动漫（美漫），
不同人的第一反应是不一样的。
有人会想到《狮子王》、《猫和老鼠》，
有人会想到《瑞克和莫蒂》、《Happy Tree Friends》，
也有人会想到《超人》、《守望者》。

不过这些都不重要，
因为跟这些_辣鸡_动画/漫画相比，
我们今天要讲的是一个更_辣鸡_的动画：

南方公园 South Park

在美国的南部，有个公园，叫南方公园。
我们有四个小学生主角：
Cartman, Kyle, Stan, Kenny.

众所周知，
小学生都是怪物。
南方四剑客（没错，这个称号就是这么中二）的日常，
也是波涛汹涌。

比如说作为一家万众瞩目的创业公司，
要开新闻发布会啦（S18E01）：

比如说作为一个变性人，
要享受自己选择厕所的权利啦（S18E03）：

比如还有 Elon Mask 的乱入啦（S18E04）：

比如里面的加拿大人都是这个画风（S18E06）：

南方公园的特别之处

Rick And Morty特别之处是它的背景、线索、剧情设定，
Happy Tree Friends特别之处是它的直白、不留情面。
南方公园(South Park, 简称SP)的特别之处是在于他的世界观：
每个人都是特别的，所有人都是愚蠢的。

SP反政治正确（Political Correctness, 简称PC），
专门搞了个校长叫 P.C. Principal.
他做的事情全部都是政治正确的，
结果被讽刺地不行。

SP也反政治不正确，
虽然PC校长一直被挂，
但最后他还是很帅地站出来拯救了南方公园，
以及发表了一番gay little speech。

SP讽刺中国人。
在南方公园的中国人是开餐厅的，
眼睛小站不直，
满嘴蜜汁口音。

SP讽刺加拿大人。
长的奇怪，
思想简单，
爱好奇葩，
连画风都跟别人不一样（字面意义上的画风不一样）…

SP更加讽刺美国人。
比如美国电视不允许出现 F-word 这个脏话，
SP就在其中的某一集里面塞了两百多个 F-word…

总而言之，
在南方公园，
所有人都会被黑。
但就是这一点让它变得特别：
想要黑人，先要自黑。

从第几集看起呢？

南方公园到现在已经有快20季，总共200集了。
但是剧情之间连贯性不是特别强，
所以想看的话可以从最新的18, 19季开始看起。
（直接到B站上搜南方公园就有资源了）

或者也可以挑一些精彩的话题性单集看：

南方公园第8季第7集：迈克尔杰弗逊 (SP S08E07: The Jeffersons)
南方公园第10季第8集：魔兽世界 (SP S10E08: Make love, not Warcraft)
南方公园第17季第7/8集：冰与火之歌 (SP S17E07/08: A Song Of Ass and Fire)

不过不管从哪看起，
也改变不了你们是愚蠢的人类这个事实。
科科。

原来我喜欢的是打底裤

Sun, 30 Jul 2017 18:24:30 +0000

以前一直觉得穿黑色丝袜的小姐姐们好好看啊，
后来才知道，
我以为好看的那些都是打底裤。

背景

以前的某个春天，
跟女朋友在街上闲逛的时候，
我感慨了一句：
“怪不得那么多男人喜欢黑丝，
PLMM穿黑丝是好看啊。“
女朋友鄙视了我一眼：
“你以为的黑丝，
其实都是打底裤。”
我：“啊？！？！？”

年幼的我对黑丝的理解很简单：
“穿在腿上的，
黑的，
看起来有丝的感觉，
那应该就是黑丝了。”

然后女朋友问我：
“你知道黑丝、裤袜、打底裤、紧身裤的区别吗？”

“……啥啥啥？能再问一遍吗。。。”

“你知道黑丝、裤袜、打底裤、紧身裤有什么区别不？”

“……噢噢噢，紧身裤我知道！
紧身的裤子！
搞摇滚的特喜欢！
就是汪峰那种！”

后来女朋友跟我稍微解释了一下，
再配合维基等解释，
我稍微总结一下这几个名词的区别：

丝袜

丝袜就是丝质的袜子，
黑丝就是黑色的丝袜。

这句话有没有很有韵律感，
感觉随时都要寻找光明了。

一般来说丝袜都比较透，
像那种腿毛比较旺盛的妹子，
假如不刮腿毛的话，
穿浅色丝袜就容易不好看。
所以从这个角度上来说，
黑色丝袜也更受欢迎。
而且黑色显瘦嘛。

裤袜

裤袜其实可以算是丝袜的一种，
分不清也不是你的错。

裤袜就是像裤子一样的丝袜，
普通的丝袜是袜子，
是两只一对的。
裤袜就只有一条，
它是连在一起的。

打底裤

首先打底裤跟安全裤肯定是有区别的。
作为一个舞区观众，
我大概很了解安全裤

打底裤是长裤，
好像说最开始功能跟安全裤类似，
都是防走光打底用的。
但是因为一些打底裤穿着很舒服，
也很自然地变成了单穿的长裤。

春秋之际路上小姐姐穿的黑色薄薄的裤子，
其实很多都是打底裤。

紧身裤

没错，就是汪峰的那种裤子。

总结

女朋友看完了我上面的解释，
表示我总结的很好，
但是理解的不对：
现在丝袜大部分也是连在一起的了，
裤袜比丝袜要厚。

我：
ToT 不听不懂不学不看，
太复杂啦。
我只知道，
原来我不喜欢黑丝，
我喜欢打底裤。

现金牛是什么梗？

Thu, 27 Jul 2017 22:31:18 +0000

最近产品经理小刘很苦恼，
因为别人一直问他，
PPT上面的现金流是不是写错了？
写成了现金牛?

故事的背景大概是，
因为客户在我们的云平台上管理会员，
所以我们想免费给他们展示一波数据，
给他们做商业决策来点帮助。

SWOT

说到商业决策的分析方法，
有个很著名的 SWOT 分析法，
会从四个维度来分析当前形势：

S, Strengths, 优势，
W, Weaknesses, 劣势；
O, Opportunities, 机遇，
T, Threats, 威胁。

比如诸葛亮在三顾茅庐作的隆中对，
就是典型的 SWOT 分析：
举个栗子，不要在意细节

优势：将军既帝室之胄，信义著于四海。
劣势：今操已拥百万之众，挟天子以令诸侯，此诚不可与争锋。
机遇：刘璋暗弱，张鲁在北，民殷国富而不知存恤，智能之士思得明君。
威胁：将军身率益州之众出于秦川，百姓孰敢不箪食壶浆，以迎将军者乎？

把 SWOT 画成奇变偶不变符号看象限的图大概是这样子：

很多鸡汤小故事里会描述一个这样的场景：

A公司以前发展很快，
但是最近陷入瓶颈了，
老板很苦恼。

后来他们花一百万美金请了专业商业公司B的人来分析，
这个B公司的人花了一个月的时间实地考察，
然后花了两天画了一个 PPT,
上面就两张图。
一张是家人合照，
因为美国人都很有家庭观念。
另外一张就是 SWOT 分析。

A公司老板很气愤：
“我花一百万不是让你来做 PPT 的！”
这个B公司的人很平静地回复道：
“是的，你画十块钱也能让别人做 PPT,
但是只有一百万才能买得到我们的 SWOT 分析。”

听了这个精彩回答，
会议场上顿时响起了经久不绝的热烈掌声。
最后A公司的人照着 SWOT 分析的建议严格地去做了，
果然药到病除，
公司又回到了飞速增长的道路上。

故事里可能扯皮的有点多，
但是我们可以大概了解到：
这种商业分析更多是用一定的姿势，
从多个角度去看问题，
最终提供了一个范用的方法论。
假如真的像故事里严格地去做这么有行动力的话，
那肯定是有正面的效果的。

BCG-matrix

那么类似的，
现金牛这个词其实是出自另外一套分析方法。

产品经理小刘预设了大家都跟他有一样丰富的人生经验，
上来就丢了这么一张图：

当然实际上他放的图更加专业，
这图是作者随便翻译和随便画的

大家有点懵逼，
然后快速地指出了图里有个错别字。

小刘没有办法，
只能给大家说了些洋文，
举了个栗子：

首先，你现在是一家跨国大型公司的老总。
你手下有二十万个员工，两百个厂房，五十多条产品线。
每月的十号都是发薪日，
作为一个不拖欠工资，
遵守劳动法，
有良心的资本家，
你发现每月九号账上还很多的现金，
十号就所剩无几了。
而且你的利润率还比隔壁黑心企业低很多。

于是你看着上文提及的五十多条产品线，开始思考：
哪些产品赚钱？哪些产品可以下线？哪些产品有增长空间？

因为你在交大读过 MBA ,
SWOT 的故事你也听过，
觉得那个是针对公司策略，
或者单个产品的。
你不想画五千多万做 SWOT 分析，
于是你请来了~~圣地亚哥~~波士顿咨询公司的人。

这群人依据老祖宗的奇变偶不变符号看象限的道理，
一边画图一边说：

To analyze the business, we should plot…

你打断了他们的施法：

Chinese please, excuse my bad English

于是他们用中文介绍了起来：

老总啊，贵司的问题很大一部分是现金流不明确啊。
这样子，我们画个图，
横轴呢，从左到右是 ** 挣钱多 > 挣钱少 **
纵轴呢，从下到上是 ** 花钱少 > 花钱多 **

于是从现金这个角度，
根据这两个维度，
四个区域我们来看看贵司的产品们。

左上角的Stars 明星产品。
这种产品挣的钱多，花的也多！
比如你们天天在电视上做广告的那个，
虽然卖得好，但是天价广告费。
别人认识贵司都是从这些产品开始，
可要保持。
左下角的Cash Cows 现金牛。
没错，这种就是花的少、挣的多的产品。
它们给贵司带来了长足的收入啊！
就跟牛一样，吃进去的是草，挤出来的是奶！
非常好！多关照！
右下角的Dogs 老狗。
别看他们现在挣得少，花的少，没啥存在感，
但他们一般是贵司的现金牛转换过来的，
比如贵司的那个老牌数码相机，
以前很赚钱的，但是最近居然被智能手机给干下去了。
这些产品有情怀就维持一下吧。
右上角的Question Marks 问题少年。
这个，挣得少还花的多，
我们还真不好预测。
比如某巨头，
之前连续十年亏损也一样头变大了。
这些产品很有可能会变成你的明星产品，
乃至现金牛。

老总觉得这很科学。
后来波士顿咨询公司回去总结了一下，
这个套路就慢慢变成了一种范用的分析方式了，
大家叫它 BCG-matrix (波士顿咨询公司矩阵)

说明

因为此文偏向讲梗，
所以很多地方夹杂魔改过的私货。
正统的横轴是 Relative market share,
纵轴是 Market growth rate，
Question Marks 和 Dogs 的翻译也是我随便翻的…
想了解更精确的内容请自行查阅维基。

程序员的二八定律

Tue, 25 Jul 2017 23:15:51 +0000

二八定律 (Pareto Principle),
泛指在各种事情中，
80%的结果是由20%的原因决定的，
这个定律一般用来定性而不是定量。

很有趣的是，
程序员们就很吃这个定律。

20%的程序员写出了80%的代码。
20%的程序员写出了80%的Bug。
80%的代码出的Bug只占20%。
也就是说有80%的Bug，是出在20%的代码里面。
为了修复这20%的代码，程序员花掉了80%的时间。
所以有80%的程序员，每天写代码的时间不到20%。
80%的程序员都有自己偏好的编程语言，但只有20%的程序员会去辩论什么是世界上最好的编程语言
80%的纷争都是这20%的程序员搞起来的。
80%的编程语言都是20%的程序员搞起来的。
一门编程语言里，只有20%的功能会被经常用到。
但是面试题目范围在另外80%里面。
假如不点名地去黑一门语言，那不管你黑的是哪个点，有80%的用户都会觉得自己喜欢的语言被黑了。
所以程序员们一般去黑剩下的那20%的编程语言。
80%的程序员都在面向对象编程，但是只有20%的程序员有对象（此数据有偏差）
80%的程序员都知道小黄鸭编程法，但是只有20%的程序员有小黄鸭。
80%的小黄鸭都被程序员抓起来了，此处应 @小黄鸭保护协会
80%的需求可以在20%的时间里面实现。
剩下20%的需求要花80%的时间去研究，20%的时间去实现，80%的时间去测试。（没错总共是200%的时间）
不还技术债的话，80%的时间连20%的需求都做不完…
坚持还技术债、不断学习、提升自我的话，那就是

10 percent luck

20 percent skill

15 percent concentrated power of will.

5 percent pleasure

50 percent pain

and 100 percent reason
to remember the name

GitHub 要怎么玩

Tue, 18 Jul 2017 23:15:49 +0000

经常会听到其它程序员说：

哎呀，又在 GitHub 上发现了个好玩的项目。

那么问题来了，
他们怎么发现的呢？

GitHub 是什么

知乎上有个万赞答案写的很好，
叫怎样使用 GitHub ? - 珊姗的回答

不过里面的图有点过时，
新版的 GitHub 大概是这样的：

学术地说：

GitHub 是一个通过 Git 进行版本控制的软件源代码托管服务，
它是世界上最大的代码存放网站和开源社区。

简单的来说：

GitHub 是程序员放程序的地方。

这里说的放不仅指存放、放置，
还有放开、共享的意思。

普通程序员会把自己业余写的一些工具放到 GitHub 上去，
文艺程序员会把 GitHub 当做写博客的地方,
2B程序员会把公司的商业代码上传到 GitHub 上去…。。。

GitHub 有什么好玩的

那既然 GitHub 是程序员放程序的地方，
听起来这么严肃，
它怎么可能跟好玩沾上边？

这个问题问得很好。
在我眼里，
所有程序员都是可爱的动物，
有一个词叫Programming Humor，
翻译成中文大概是代码之趣。
比如我很喜欢的XKCD系列漫画，
就有很多关于代码的好玩的梗：

（我凭本事丢骰子丢的4，
你为什么说这个数字不够随机？）

（Python 大法好！）

GitHub 上也有很多很好玩的东西。

比如etilqs的梗:

有个小型数据库软件叫 SQLite ，
它非常好用。

于是知名杀毒软件 McAfee 就用了这个数据库，
McAfee 还以 sqlite_ 当文件名丢了很多文件在C盘放着。

不懂计算机的用户们，装上 McAfee 以后发现，
C盘多了好多奇怪的文件。

于是他们有些人 Google 到了 sqlite 的研发工程师的电话，
半夜打电话去吵醒工程师，
问C盘里多出来的这些文件是干啥的……

后来 sqlite 就决定把临时文件的名字改成 etilqs。

假如有人能分别得出这个词，
是 sqlite 反过来写。
那以他的智商，
也不至于半夜打电话叫醒 sqlite 的研发工程师了……

比如前阵子，
好几家公司有新闻的时候，
就有个programming-job-blacklist的项目，
列了一堆程序员找工作的黑名单公司
（列表皆整理，请谨慎食用）

当然，
还有酷炫的“是男人就一年不断 Contribution”的刷 Contribution 的项目。
一分钟就可以让你变得绿油油的：

那 GitHub 要怎么玩呢？

正如鲁迅说过：
有人的地方就会有江湖。

作为一个以 UGC 为主的网站，
我们当然是要关注更多的用户。

我在 GitHub 上主要关注了三种用户（此分类不正交）：

一般意义上的大神，这些人粉着以示膜拜。
比如从胖子变帅哥的Python程序员Kenneth Reitz，
经常可以看看他又被哪个组织拉进去了，
又给哪个项目贡献代码了。
项目作者、文章博主，这些人做的东西往往看着更好玩。
比如羡辙学姐，
占着一个巨好的 GitHub ID 不说，
我对前端的不少了解都是羡辙和尤大的feed刷出来的。
比如皓哥，
虽然他目前好像忙着搞事，
不过毕竟是一直奋斗在写代码一线的我辈楷模。
我喜欢的身边的朋友，平时有更多可能性交流技术。
比如有基友ldsink，
toolbox的一些脚本非常好用。
比如有交大魔法师hcz，
很多好玩的项目都是他给我的timeline刷出来的。

所以总结一下。

GitHub 就是这么一个本来是放程序，
但是被玩成了同性交友的社交网站…

（嗯，本文以一个讲梗的角度讲了下 GitHub ）

那当然是选择原谅她是什么梗

Sun, 02 Jul 2017 23:05:08 +0000

“她做了对不起我的事情，该怎么办？”
“那当然是选择原谅她啦！”

绿帽子

绿帽子这个词好像流传已久了。

有说是春秋时期，
卖淫为生的人的家人要头裹绿巾，
以分贵贱。

还有个比较逗的说法是，
古代有个已婚女士搞外遇，
每次早上丈夫出门，
她都给丈夫戴上一顶绿帽子，
以此作为明显的暗号。

总而言之，
不论如何，
这个偏侮辱性的词语就流传了下来。

不过最近的一个梗把这个侮辱性给弱化了…

那当然是选择原谅她

这个短句的出处也是不一的，
有说是卜同学，
也有说是白同学…

不过事实就是最近的表情包的确为它的热度推波助澜了：

后来逐渐发展出了原谅帽系列表情：

还有人做了原谅帽的游戏…
green.ssyar.com

当然，
这个梗火了以后就会有对应的讨论：

知乎：“当然是选择原谅她啊”系列表情图是不是歧视女性

知乎：“当然是选择原谅她啊”系列表情图是不是歧视男性

…

不过这个表情包真的很好玩啊，
每次我们谁写了个bug，
多了个需求，
就一下子想到了原谅帽了…

Saint Patrick’s Day

爱尔兰有个节日叫Saint Patrick’s Day，
大概讲的就是很久很久以前，
有个厉害的人到爱尔兰，
向大家传播了基督教感化了大家…

于是在那一天，
大家都会穿上爱尔兰国旗颜色（绿色）的衣物、袜子、帽子，
聚在一起，
喝酒…

就像中国人，
不论什么节都会过成情人节一样。
外国很多节，
最终都会变成喝酒的节…

那这该怎么办呢？
当然是选择原谅她啦~

写程序的我的性格

Sun, 02 Jul 2017 00:20:23 +0000

写程序真开心啊。

前阵子面试频繁的时候，
有一个工作了七八年的兄弟在简历上写，
自己大学学的是Java，
工作以后做的是全栈，
所以有十多年的Java开发经验，
七八年的前端开发经验，
还有若干年的Blabla…

当时周丞和我就很无奈，
假如工作经验真的是这么算的话。
那中学时期就开始参加OI的同学，
岂不是都是十年软件开发经验起步了？

经验

我一直觉得软件开发的，
或者说程序员的，
“工作经验”是一件很扯的事情。
因为假如程序员停止了学习、思考与进步，
那么一个有十年工作经验的人，
只不过是工作的第一年学习了一年的工作经验，
然后又重复了九年。
真正的十年工作经验，
应该是那些“苟日新，日日新，又日新。”的人。

有一句俗话叫
朝闻道，夕死可矣。

这句话的意思就是一个人早上听到了一个很科学的道理，
想了一天，
到了傍晚终于发出了“死可矣”(すごい)的感慨之声。

当然，
人的一生不可能每天都在学习崭新的姿势，
就算某一天了解到了新的知识，
也不一定能够消化吸收，
说不定隔夜就忘了。

不过我们人类这种生命，
正是所有过去的积淀。
我们读的书、
吃的饭、
做的事情都会消失，
但是我们的生命会越来越厚重。

举个栗子，
我是记不得我写过的每一行代码的，
但是我能清晰地感觉到，
我身上有些特质，
和写程序有着一定的羁绊。

懒
科学
试试看
问个问题

懒

Quora上有个问题是
聪明人里面，懒人是不是比勤奋的人贡献更大？
有个回答我非常喜欢：

“I divide my officers into four classes; the clever, the lazy, the industrious, and the stupid. Each officer possesses at least two of these qualities. Those who are clever and industrious are fitted for the highest staff appointments. Use can be made of those who are stupid and lazy. The man who is clever and lazy however is for the very highest command; he has the temperament and nerves to deal with all situations. But whoever is stupid and industrious is a menace and must be removed immediately!”
— General Kurt von Hammerstein-Equord

在我眼里，我的下属们一共占了四种属性：
聪明的、懒的、勤奋的、蠢的。
他们每一个人都占了两种属性以上。

那些既聪明又勤奋的人会做最重要的事情，
同样地，那些又蠢又懒的人也只会做最不重要的事情。
一个聪明的懒人也可以做很重要的事情，他有能力去处理各种事态。
假如一个人不仅蠢，生产力还巨高，那得马上开掉他！
by 一个可能有名的将军

我部分赞同这个答案，
因为我不仅自认为是一个聪明的懒人，
我还认为大部分好的程序员都是聪明的懒人。

程序员很喜欢干的一件事情就是“自动化”。
GitHub之前有个很火的Repo (NARKOZ/hacker-scripts)，
讲的是有个程序员离职以后，
其他同事在整理他写的程序。
发现他不仅写了一个自动泡咖啡的程序，
还写了一个“假如晚上九点电脑还开着，就随机编一个理由，给老婆发短信说会晚回家…”

所以我想说的懒，
其实是“程序员式的懒”：
不是不想干活，
而是不想干重复性的工作；
相比于简单但重复的解决办法，
更愿意选择工作量大但一劳永逸的办法。

毕竟聪明人支起世界，
懒人改变世界嘛。

科学

我有两个口头禅，
一个是“这很科学”，
一个是“这不科学”。

一方面，
我认为“万物都有自己的规律”，
“物理世界存在大一统定律”，
“事出反常必有妖”，
“程序不会自己出bug，都是人写的”，
“多用git blame我们就能找到那个人了”。

另一方面，
我也认为“人类是愚蠢的，是短视的”，
“所以很多规律人类都没发现，比如关于人类自己的”，
“像老师、HR、销售等，跟人打交道的，都是厉害的”，
“更别提艺术那种，一千个人就有一千个freestyle的学科了”。

比如程序员修bug，
首先第一步要做的就是问一句：
“能重现吗？怎么重现？”
假如一个bug不能重现，
我们就会说：
“我这咋是好的，重现不了，不修了。”
假如一个bug不能重现，
但是它很严重，
必须要修复，
我们就会感慨：
“卧槽，这不科学啊…”

试试看

直到目前为止，
程序都是为人服务的。
人是活在现实生活中的，
所以实践证明一切。

假如两个程序员battle，
基本上一句话可以终结：
Talk is cheap, show me the code。

因为万事万物都是有规律的，
一定的条件下，
试一次就可以学到了。
比如压缩食物怎么样？试一试呗。
创业公司是什么样子？试一试呗。
Kotlin和Java有什么不同？试一试呗。

就像诸葛亮用标记重捕法发现南蛮之地盛产孟获一样，
程序员也经常会用控制变量法来尝试。
比如之前说的重现一个bug，
试试ios，试试安卓，
试试win xp，试试有360的电脑。
世界这么大，
我们总会再见的。

问个问题

小时候看过一个比喻，
说人的知识是一个圆，
知道的是面积，
不知道的是周长。
（翻译成鸡汤就是“你知道的越多，你不知道的也越多”）
果然鸡汤披上了科学的外衣，
就额外迷人呢…

写程序做技术也是一样，
学到了更多的知识以后，
觉得未知的世界更大了。

大四的时候第一次实习，
那之前只是把git理解为一个ftp一样的放文件的工具，
VIM更是从没用过，
所以我心中的问题那是多的一比。

我实习的公司QAD给每个员工会安排一个Mentor，
可以类比于“老师傅带徒弟”的模式。
第一天入职的时候我找到自己座位坐了下来，
发现离我最近的同事叫Justin，
于是问他：“你是我的Mentor吗？”
(那时刻有种Saber问士郎的蜜汁即视感…)
他笑了笑说：“我也不知道啊”
最后发现其实他知道自己是我的Mentor -.-

一开始我经常会问他git怎么操作，
比如说John往dev分支提交了最新代码，
我想用他的一个函数咋办。
他就会站到我身后，
一个字母一个字母把命令说出来，
然后让我敲一遍：
“打开Putty，git，G I T，空格，rebase，R E B A S E…”
因为有种自己被当成智障的感觉，
所以我压力山大地操作完了以后，
又上网查了一遍我刚才做的操作是什么意思…
这样来回几遍以后，
我发现自己收获很大啊，
之后git相关问的就越来越少了。

所以直到现在，
我还是很愿意当一个智障的好奇宝宝。
先看，再问，后想，
只要问到了，就是学到了。
每个人都有自己独到的厉害之处，
这个道理就跟老祖宗苏轼说的一样：

吾上可陪玉皇大帝，
下可以陪卑田院乞儿，
眼前见天下无一不好人。

苏轼写文章的能发这样的豪迈感慨，
我写程序那也可以一样豪迈呀 :)

写程序与取名字

Sat, 24 Jun 2017 19:36:17 +0000

据说平均下来，
程序员会有10%的时间花在取名字上。

今天和俊儒聊天的时候，
讲到了在知乎上看的，
《扩散性百万亚瑟王》为什么停运的原因：

这种等级的中二程序员的确可以留名青史了…
大型程序一般都是团伙作案，
所以“写出逻辑清晰、见文知意”的程序，
也是一个程序员的必备技能。

按照正常文章的套路走，
这里我们要介绍一下，
绝大多数的计算机词语是有唯一的中英对照的：

服务器 - Server
表 - Table
事务 - Transaction
等等

像这类词语一般来说都没啥异议。
写程序的时候就直白地写就行了。
不过有的时候程序员要写富含需求的代码，
就可以玩一玩了。

代码片段

之前有一段代码，
要实现软文、软广相关的功能。
于是取变量名时，
翔神一拍大腿：
那就是advertorial这个词了！
这个词非常准确，
就是软文的意思。
吃瓜群众纷纷表示真牛逼！

然后代码写好了，
到浏览器里跑一下：
结果后端接口调用挂了…
定睛一看，
原来是浏览器的防广告插件自动识别了advertorial这个词，
把我们的接口屏蔽了…
…
于是后来数据库里，
软文还是advertorial，
但是url里，
软文变成了soft_article…
吃瓜群众纷纷表示更牛逼了…

还有一段代码，
要实现一个大礼包相关的功能。
类似于星巴克88元的礼品卡，
送券送积分送储值等等…
于是问题来了，
这个“大礼包”的抽象类应该叫什么名字呢？

当时系统里面已有的一些英文对照有：
积分奖 reward, 券 coupon, 礼品卡 gift_card等等……
感觉好的名字都用完了，
我们都停下了手里的键盘，
开始了头脑风暴…

gift_bag感觉很蠢，
尤其是有了gift_card。

这种奖励是一系列产品的叠加，
也可以叫production，
但是这会跟production environment有歧义。

最终我们给这个东西取名叫：
one_piece。
没错，OnePiece就是《海贼王》里面的海贼宝藏。

给抽象类取一个无意义的名字，
反而影响深刻，没有歧义。
简直是解释一次，终生难忘…

信达雅

其实写程序起名字，
很多时候随便起一个也很容易，
但是想追求一个信达雅的表达，
就需要仔细想想了。

最近业余时间写麻将相关代码，
就感觉翻译真难…
像花色和大小还能用纸牌的Suit和Rank来对应，
但是一些番名我就比较懵逼了：

十三幺/国士无双，根据维基百科的说法是ThirteenOrphans
- 那老头牌估计就是OrphanTile了…
九莲宝灯，有翻译说是Nine Gates，这个我先信了…
海底捞月，杠上开花这些咋办…

:) 所以看来10%时间都花在取变量名上，
这个说法还是比较保守的呢。

正如程序员经常说的
Talk is cheap, show me the code，
有个有个很棒的翻译：
废话少说，放码过来。

还是要继续修炼啊。

我的工作

Sun, 11 Jun 2017 13:49:36 +0000

前两天和家里打电话，
聊到了工作上的事情，
我多讲了几句，
虽然爸妈听不懂，
但他们听的很开心。

我一直是个粗糙的利己主义者，
有的时候会过量地我行我素。
难得有个机会思考一下，
就借此写点东西，
记录一下我现在的工作生活吧。

再惠

去年十月左右，
百姓网的HR PP找到了我的GitHub，
要了我的简历，
约我到百姓网面试。

因为大学室友周丞之前就是在百姓干活的，
我就去问他百姓各方面怎么样。
他大概讲了一下他眼中的百姓，
然后问我是不是在找工作？
不如顺便发个简历来？
帮我内推一下？
我问他现在在哪工作，
他说在再惠，是个创业公司。
我第一感觉再惠这个名字听起来不响亮，
于是上网搜了下，
结果除了融资的新闻和官网，
没搜到任何有意义的信息，
连吐槽面试的贴子都没。
我又去知乎搜了一下再惠，
然后没搜到问题和回答，
只搜到两个人，
一个是创始人之一赵洋，
另一个就是周丞-_-…
当时总有一种再惠不靠谱的感觉，
不过感觉周丞现在还是蛮开心的，
应该不像是在传销组织？
（毕竟看过很多被熟人带进传销组织的故事）

结果没想到最后经过一番面试和抉择，
我还是加入了再惠这个传销组织 :)
（这句当然是玩笑话）

我司①，也就是再惠，是做SaaS系统的。
呃，其实我也搞不太懂这个词，所以按目前的情况来说，
我们主要在做餐饮行业的会员系统解决方案的。
举个栗子。

周末我和女朋友打算出门吃顿好的，
在大众点评上看到了魔都有家网红餐厅暗恋桃花源，
于是决定去吃这家店。
吃完饭以后买单，
服务员提示说扫码成为桃花源的微信会员可以享受满100减5的优惠，
于是我很开心地扫了桌子上贴的二维码，
然后关注了桃花源的公众号，
之后在公众号里用微信支付买了单。
之后过了一周，
某一天突然桃花源的公众号给我发了张“桃花源常伴你身旁，下次消费可以全单九折”的优惠券。
然而有钱的我不想为九折优惠跑一趟，不为所动。
再惠的会员系统就学习到了原来小额优惠打动不了这个顾客。
又过了两周我突然收到了一张优惠力度更大的八折优惠券…
因为这家店味道和风情都不错，
我最终又回去吃了一顿 :)

没错，上面这段话里的粗体字，
除了大众点评都是我司的业务内容~
大众点评做的更多的是拉新，拉流量，
我司做的更多的是留存，维持会员关系。

比如我司有个经典客户案例，
商户叫玲珑宝宴，
店是开在饿了么公司附近的某个角落里…
之前一直是流量一般，没有盈利的状况，
老板还想过关掉门店。
但后来用了我司产品以后，
效果拔群！
也许是各种优惠吸引了饿了么程序员吧…
后来饿了么的人来面试，
他们还很开心地说过：
“诶我知道再惠，我用过你们的产品…”

过程和结果

正如黑恶势力老大训斥小弟说的那句：
“蠢材，我们的事业是正义的！”一样，
很多时候体验都是独一无二，因人而异的。
我很喜欢目前的工作，
一个原因是因为做事的过程十分敏捷。
没错就是那个Agility，
每一点敏捷增加1的攻速②。 :)

前几个月我写过一个bug，
是给微信的一个接口，
文档上规定接口一定要返回success这七个小写字母。
但有的时候微信会给我们发文档上没提的错误消息，
我就想当然地回复了fail…
于是，
第一天写的代码，
第一天晚上发了新版本，
第二天我们的公众号全部报错不能用了……
这就是敏捷…
（当然后来研究了一会就修好了）

我们还有家商户叫雨树湾/胡姬兰③。
他们有个需求，
就是点套餐会免费赠送一杯滴滴咖啡，
但是为了对账，
这杯咖啡在点菜机上的价格是一分钱。
于是会出现客人在公众号里买单时，
因为送了两倍滴滴咖啡，
结果要付100.02块钱的恶心情况…
当天上午知道这个情况以后，
我们迅速讨论研究了一下，
抉择以后写了段代码特殊处理0.01元的情况，
然后又发了个版本，
于是下午买单的客人就不用多付那几分钱了。
这也是敏捷…

除了敏捷的做事过程，
还有一个很棒的是透明的结果。
也就是说我们做的所有东西，
都会很快、很明显地反映出来。

前阵子我们做Growing Hack的时候，
成立了一只诺曼底分队④。
他们的任务是到店 ~~公费吃喝~~ 观察客人是怎么用我们产品的。
然后老板就会跟他们吐槽
POS机难用啊、
支付流程太麻烦啊、
客人不愿意加入会员啊、
POS机难用啊等问题。
这种时候小队队员们也只能苦笑着替大家背锅了…

还有一件很惊奇的事情，
就是我来面试的时候，
前端爸爸同济大佬靖哥哥⑤在面试过程中，
掏出了他的大电脑，
连上了数据库，
直接SELECT COUNT了一下，
然后直接跟我展示数据库里我们多少条用户记录，多少条商户记录…
我就惊了，生产环境也能这么玩，感觉是好玩啊…

既然过程到结果都是很愉快，
再加上写代码本来就很有趣这一点，
我的日常基本上就是：
开心地写代码、
开心地发版、
开心地吃饭、
紧张地修bug、
开心地发版……

后端工程师

现在的公司是再惠，技术团队不到20人，每个人都很强，我感觉自己是里面最菜的 :)

正如我在个人介绍里说的一样，我们技术团队不到20人 ;)

目前分工如下：

1个当CEO的（以前可以算1个技术，现在大概算是0.5个技术吧）
2个Windows端工程师（我们要Hack别人的点菜机）
2个Android端工程师（我们要写自己的商户端App）
6个后端工程师
其他都是前端工程师…

我是六个后端之一。
后端的主要职责有：

实现业务API。比如上面讲到的支付流程，公众号看到漂亮的支付页面这部分属于前端，输密码支付然后扣钱给商户这部分就是后端。
打理数据库。比如之前传出的炉石数据丢失、某酒店开房记录泄露这些都是后端的锅…
管理服务器。比如这破网页怎么这么慢一般也是后端的锅…

平常用的语言是Python，
这是门很简单的语言，
当HR的女朋友也可以很快学会
（不过相对于写Python，显然她对看奇葩说兴趣更大…）

不过好像我大部分时间都花在了Chrome上…

总的来说这些就是我的工作了，
希望个人的奋斗能赶上历史的进程吧。
一切安康。

① 我司：就是我的公司的简称，好像是华为先用这个词，然后传播出去了，不是很正式的词。

② 敏捷和攻速：是游戏里面的一个梗。很多游戏会分力量、敏捷、智力三种人物，游戏里的敏捷一般是名词。

③ 雨树湾和胡姬兰：这家店做新加坡菜的，还蛮好吃。胡姬兰是新加坡的国花。他们店一开始叫雨树湾，后来改回胡姬兰了，更有辨识度。

④ 诺曼底分队：取名自诺曼底登陆。我司取名一向富有风格，比如羊晨羊晓、神付、SoftArticle、OnePiece等~~内部黑话~~…

⑤ 前端爸爸：内部互膜文化盛行，类比于敬酒时两个人会争先放低杯位然后趴到地上，我们互相也会称呼XX爸爸、XX老板、XX老爷等…

我也看完了《人人都是产品经理2.0》

Sun, 21 May 2017 00:18:14 +0000

最近把很有话题性的《人人都是产品经理》看完了，
看的是2.0版本，这大概是个读后感吧。

这本书其实是入门级别的科普读物，
作者试图用简洁的语言、生动的例子和必要的术语来诠释产品经理（Product Manager）的日常。
因为书的定位不是教材，
所以指望看这本书能像看《算法导论》一样学到算法，
看《代码大全》一样学到代码之道是期待过高了。
不过这本书很多地方的视角还是很特别、很好玩的
:) 或者说有的时候从比较PM的角度来看问题的确会好玩一些。

比如书里提到一句

只做一次的事情求可行解，反复做的事情求最优解。

这句话就很科学。
因为写程序的时候也是这样的。
有些出现频次低的需求，
程序员就会写个脚本去做。
而假如这个需求老是出现，
那程序员就会重新审视问题，
完善地考虑一遍，
再优化/重做之前的脚本。

书里还有一句话（稍微凝缩一下）

对某个领域的激情是能通过做过什么而看出来的。“做过什么”是指“输出”而不是“输入”。比如看过什么书，逛什么网站都是输入。而写过一些言之有物的文章，做过一些哪怕很小的Demo，都算输出。

虽然这段话是说怎么面试PM的，
但其实任何事情都是这个道理。
举个栗子，
我最近已经不敢说“我很喜欢二次元文化了”。
因为我很长一段时间都没投过视频，
参与动漫相关的讨论，
甚至没发过弹幕（惭愧）
所以即便我没事会看一些动画、漫画，
这些也不过都是输入而已，
我并没有什么输出（滑稽）

我很喜欢的一个小节

书里有一个小章节，叫《如何通过提问把别人干翻》
大意是别人在讲PPT的时候，
你可以提这些问题来把他干翻：

为什么要做这件事，不做的话会死人吗？

这是用户的目标还是我们的目标？是不是老板的目标？老板换了怎么办？

这个用户有普遍性吗？能代表多少人？这类用户对我们优先级是什么？

数据来源是什么？什么时候获取的？是怎么采样的？

为什么没有看到这个产品线的大图？5年后这个产品是什么样子？你实现整个图景的途径是什么？

未来的确很美好，但怎么实现？现在如果只做一件事，最重要的是什么？你打算怎么做？

……（还有很多）

光是粗略的看了一遍问题，
我已经能想象会议室里的尴尬的沉默了……

其实《把别人干翻》的这系列问题，
跟《如何写出无法维护的代码》的意思都是一样的，
通过反向的思考（假如我是刁民）来完善自我。

好奇心与行动力

书里很多次地提到过一对词：【新手】和【专家】。
而且后面还说
“一个好的PM不仅有新手心态，热爱思考，拒绝存在即合理。
也会有专家能力，很快上手，做什么事情都很擅长。”
~~呸…这又不是PM专属的…作者真不要脸 :)~~

其实我眼中这就是两个词：
好奇心和行动力。

好奇心会促使我们看到一个东西时，
想去玩一下体验一下，
然后试图搞清楚它的原理。
也会激发我们透过现象看本质，
比如XYZ问题里的道理一样，
透过Z问题，越过Y问题，看到最初的X问题。

行动力可以帮助我们满足好奇心。
陶菲格在自己的文章里质问自己：
“（为什么我要践行我的思想呢？）
难道只有我的头脑中才有思想？”
而他自己又回答道：
“其他人也有思想。
但是能让思想出世的却寥寥无几。”

复用上文的的说法，
好奇心会增加输入，
行动力会把输入转化成有用的输出。

总的来说作为一个外行人，
看《人人都是产品经理2.0》这本书的确增长了一点眼界。
不过假如人人都是程序员就更好了 XD

Vim, Tmux, Zsh怎么读

Fri, 12 May 2017 22:41:02 +0000

孔乙己显出极高兴的样子，将两个指头的长指甲敲着柜台，点头说，“对呀对呀！……回字有四样写法，你知道么？

前阵子 GitHub 上有一个很好玩的 Repo ：
shimohq/chinese-programmer-wrong-pronunciation

列了一些国内程序员容易读错的词，
过了一遍我发现我也中招了：
Django 读作 Jango 就行了，D不用读出来

Vim 怎么读

这让我想起前阵子听冰河学长和别人聊 Common Lisp 的时候，
（一个多小时的纯聊天，听完收获很大）
把 Vim 单个字母地读出来读成了 V - I - M …
当时我就很好奇地去查了一下大部分人是怎么读 Vim 的。
结果在万能的 Vim Manual 里发现了 :help pronounce，
里面是这么说的：

Vim is pronounced as one word, like Jim, not vi-ai-em. It’s written with a
capital, since it’s a name, again like Jim.

也就是说 Vim是一个词连读的，就好像读Tim一样，很科学

Tmux 怎么读

不像 Vim 的读法，有一个比较官方的说法。
Tmux 的读法可以当做辩题…
比如 Reddit 上有小伙伴说，公司里因为没有统一的 Tmux 读法，所以很多人都装了 Screen…

不过 大部分人都觉得 Tmux 应该读作 Tee Mucks

比如下面有个比较靠谱的回复说，

Tmux 应该读作 Tee Mucks，因为 Tmux 其实是 Terminal Multiplexer 的缩写，所以应该读作 T-Mux (Tee Mucks)

又有人说：

Tmux 的发音规则很简单，就跟 Gmail 一样

Zsh 怎么读

其实类似于 Tmux，大部分人觉得Zsh 应该跟 Tmux, Gmail 一样发音
因为 Zsh 全称是 Z Shell：

~~其实也可以说纠结读音的人，都是PM需求提的不够多（滑稽）~~

总的来说，
我喜欢兼听则明。
能听懂不同发音指向的同一名词，
也能选择自己觉得最科学的发音来与人讨论问题 :)

我可能看了假的技术书

Sat, 22 Apr 2017 01:48:05 +0000

清明节的时候在火车上把 How Google Works 给读完了，
我原以为读这本书会提升技术，
没想到提升了 HR 的知识（懵逼

这本书讲啥

写书的人叫 Eric Schmidt，
是 Google 的 Executive Chairman。
然而我并不知道这个职位具体是做啥的，
大概翻译成中文会是“执行总裁”，
感觉做很多管理相关的工作。
不论如何，这个职位是不写代码的。

这本书条理极其清晰，
整本书的内容用章节小标题即可概括：

像创始人一样工作

放权于员工

只聘用比你优秀的人

不要把职业发展和绩效管理混淆

关注团队的两端：最好的和最差的员工

既要节俭，又要慷慨

不公平薪酬

助推 这个翻译太屎了

能力越高，期望越高

享受你的工作

读完这本书基本上我的感想如下：

卧槽，外国人的英语是溜啊
不愧是谷歌，有些东西是只有他们才能这么搞，规模效应是厉害
在吹牛逼之前，首先你得变得牛逼

书里的招聘

前几章的重心都在招聘上，
作者讲到一条大家都认同的道理，
就是面试是无法精确衡量一个人的水平的。
所以对此，他们采取的解决方案就是
招聘Top10%的人才，这样他们就算表现再差，也只会是中等水平。
看到这里，
我总有一种我要买最贵的食材，这样做出来的菜就不会太难吃
的浪费的感觉…
大厂毕竟是大厂啊…（心酸地、嫉妒地

作者还讲到了一个词，
叫 Exploding Offer（会炸的录取通知书） 依然是屎一样的翻译
说是他们会给来面试候选人发有最后期限的offer，
比如 下周三之前，不接受我司offer就失效。
这种发offer的方式，从公司、管理角度是非常棒的，
因为可控风险，防骑驴找马。
不过对于个人而言，
作者也觉得这种发offer的方式并不完美。
这里用“也”，
是因为我也觉得这种发offer的方式不完美。

除了这些，
作者还讲到了一些好玩的点：

面试一定要保持恒定的标准，最好采用结构化的测试问题
没人喜欢现有的绩效考核制度，包括HR。
更没人喜欢任何新的绩效考核制度。
在一个组织里，更多时候是幂律分布，而不是高斯分布。

总的来说，
这本书可以休闲的读一下。
里面有不少故事，
但是里面的方法论不一定学得来，
毕竟所有的这些构成了 Google 独特的文化，
就好像 Valve员工手册里独特的 Valve 文化一样。

hunter2是什么梗

Sun, 26 Mar 2017 23:58:26 +0000

简单来说：
这是一个弱密码。

hunter2

密码安全是个长盛不衰的话题，
前阵子又有人统计了2016年最弱的密码。
每次明文存储密码的大网站数据库泄露，
也都有人统计弱密码排名。

像123456、letmein、password都是典型的弱密码。
hunter2也是一个弱密码，
其中的梗起源于2004年左右IRC上面的一段对话：

<Cthon98> 在聊天框里输入你的密码，系统会自动地把它变成星号
<Cthon98> ********* 你看！
<AzureDiamond> hunter2
<AzureDiamond> 我看不到星号
<Cthon98> <AzureDiamond> *******
<Cthon98> 我看到你发的是上面这行
<AzureDiamond> 哇哦，真的？
<Cthon98> 没错
<AzureDiamond> 你用hunter2把我的hunter2给hunter2了
<AzureDiamond> 哈哈，你看这串是不是很有意思
<Cthon98> lol 是啊。所以说每次你输入hunter2，我看到的都是*******
<AzureDiamond> 真是酷炫，我以前都不知道IRC会自动屏蔽密码
<Cthon98> 是的，不管你在哪输如hunter2，别人看到的都是*******
<AzureDiamond> 屌爆啦！
<AzureDiamond> 等等，你怎么知道我密码的？
<Cthon98> 呃，我只是把你的*******给复制了一下，你看到的可能是它的原样hunter2

用表情图表示就是这样子：

这样的套路在新时代就是这样子的：
~~（今天是马化腾的生日，转发你的密码到五个群，再看看你的头像）~~

[XKCD 936]也是讲密码安全的：

于是某Redditor也发现了，
写教务处网站的那个同学，
也看XKCD：

所以总的来说，
hunter2就是一个关于弱密码的梗。
希望大伙的密码都很安全，
相关的虚拟财产什么也都很安全 :)

其它

在如今，用一个好的密码管理软件是很好的选择。
假如你嫌密码管理软件太麻烦，
那么选一个有数字、大写字母、小写字母、特殊字符的10位以上的密码也是不错的选择。

然而有很多网站不支持特殊字符ORZ
还有网站限制了很短的密码长度…
╮(╯▽╰)╭ 假如网站登录框旁边，
能把他们当初注册的密码条件写上就好了。

搭建舒适的 Windows 开发环境

Fri, 24 Mar 2017 02:00:55 +0000

假如你也不介意身处鄙视链的最底端，
那来交流一下怎么样搭建Windows的开发环境吧

鄙视链的最底端：Windows

鄙视链是程序员日常生活中确实的一部分，
比如拿经典的编程语言来说，
有种说法是：

C 语言工程师鄙视 C++ 工程师，
C++ 工程师鄙视 Java 和 C# 工程师，
Java 工程师和 C# 工程师则互相鄙视。
写静态语言的工程师鄙视写动态语言的工程师。
用 Python 3 的工程师鄙视还在用 Python 2 的工程师，
用 Python 2 的工程师鄙视遇到 UnicodeEncodeError 的工程师。

所有的工程师都鄙视 PHP 工程师。

而在用的操作系统方面，
鄙视链的说法基本是这样的：

用 Mac OS X 的工程师鄙视用 Linux 的工程师，
用 Linux 的工程师鄙视用 Windows 的工程师。

虽然是这么说，
但我还是很喜欢 Windows 的开发环境，
主要原因是：可以玩游戏…
虽然目前我已经几乎不玩了，
但是这个可以玩游戏的无限可能性深深地吸引着我…

o(〃‘▽’〃)o
所以我们要通过一系列步骤，
搭建一个最舒服的 Windows 开发环境！~~和游戏环境~~

必备软件

有几个软件我认为是 Windows 开发环境中必不可少的。

Chocolatey

Chocolatey 是 Windows 上的命令行包管理软件，
不是官方的，
但是非常好用。

以管理员身份打开 cmd.exe 后运行一行命令即可装成功：

@powershell -NoProfile -ExecutionPolicy Bypass -Command "iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))" && SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"

装好以后一行命令就可以装上常用软件，
以及把 Path 环境变量配好：

choco install -y 7zip everything git jdk8 nodejs npm python2 putty vagrant virtualbox vim wox

唯一缺点是安装过程都是采用默认值静默安装的，
假如有些软件要取消掉右键菜单，
或者放在特定文件夹内则需要自己搞一下。

Wox

就是上一条 choco 命令最后要装的那个 wox ，
一个快速启动应用的工具。

假如你知道 Mac OS 系统上的 Spotlight 或者 Alfred 的话，
wox 就是它们在 Windows 上的版本。

比如我在任何界面，
敲下 Alt + Space 的快捷键以后，
就弹出了白色的输入框。
我输入程序名后按下回车，
就会自动打开该程序。
wox支持通配符，
支持搜索，
支持系统操作（比如锁屏、重启），
加上 everything 以后支持搜索文件。

Git Bash

此处讲的不是 Git ，而是特指 Git Bash。
Git Bash 是装 Git 附带装的基于 mingw (MINimal Gnu for Windows) 的一个终端软件。
自带 bash / ls / find / grep / wc 等 Linux 命令行工具，
支持 .profile 自定义环境变量，
支持 git 文件状态显示。
有了这个以后我基本没用 cmd 或者 powershell 了。

我的偏好

前文的三个软件我是强烈推荐使用的。
下面还有一些带有一定的，
或者是强烈的个人品味的软件。

VirtualBox + Vagrant + Putty：平常开发的时候，我会用 vagrant init ubuntu/trusty64 && vagrant up 来起一个 Ubuntu 虚拟机，然后用 Putty 连上去，把这个虚拟机当一个完全体 Server 来用。VirtualBox 是虚拟机载体，类似于 VMware ，但是版权协议更宽松。Vagrant 是虚拟机管理软件，提供主机与虚拟机的数据通讯，还有一些自动化的活。Putty 是老牌远程终端软件。
JetBrains全家桶，包括IntelliJ IDEA, PyCharm, Rider EAP, ReSharper：JetBrains 毕竟是做 IDE 的商业公司，还是比_一些_开源 IDE 要好的，比如他们家的 IDE 基本上不会出现10年都没解决的Issue…
网易云音乐 + 有道词典 + 有道云笔记：呃，这个不知道怎么介绍，就大概是字面意义上的需要这些东西吧。咖啡和音乐是程序员的好伙伴，我不怎么喝咖啡，我就只有音乐了。
everything：巨快巨好用的 Windows 全局搜索软件，效率可比 Linux 上的 locate 命令。
Vim, Windows 上的是 GVim：编辑器之神。

其它技巧

左耳朵耗子的建议：作环保的程序员，从不用百度开始
除了 Alt + F4，Windows上的 Win + E, Win + R, Win + D, Win + L, Win + Tab 也很有用。
而可以用 终端中左键选中 来复制，Shift + Insert 来粘贴。
Windows 中与 ln 类似的命令是 mklink <dest> <source>。假如是目录则要加参数 mklink /d <dest> <source>
假如你用 Vim，把 <Caps Lock> 大写锁定 键改成 <Ctrl> 键吧。
本文中用到的一些配置，也可以在我 GitHub 的配置项目中找到。

HR与程序员的日常（一）： HRBP与Markdown

Mon, 20 Mar 2017 01:49:00 +0000

简单来说，
HRBP是一种角色，
Markdown是一种语法。

Lirian是男程序员，
Mia是女HR。
他们经常会互相科普各种名词，
Lirian决定把谈话记下来。

HRBP

话说某一天Lirian问Mia：
“问个问题啊，HRBP究竟是什么？”

Mia十分惊奇：
“怎么想起问这个了，贵司要招HRBP么？”

“不是不是，我就是好奇一下。
比如先说HR吧，我在想，
HR的全称其实是Human Resources，
直译过来就是人力资源。
那假如说‘我是一个HR’，
直译过来岂不是‘我是一个人力资源’了么？
感觉怪怪的。”

“哎呀，这个是习惯用法啦。”

“那HRBP呢？HRBP全称是什么？”

“HRBP的全称是Human Resources Business Partner。
你首先得要有一个概念，
HRBP它广义上不是一个职位，
而是一种角色定义。”

Lirian很困惑：“什么意思？”

Mia并没有直接回答这个问题，
而是抛了另外一个问题：
“我从源头上跟你讲吧。
传统意义上人力资源的分类，
是分成了六大模块，
这个你知道吧？”

Lirian表示知道：
“我想想啊，你别说啊，
六大模块应该有招聘，培训，薪资…呃…
呃…和其它三大模块！”

“嗯，你前面的招聘、培训、薪资福利都说对了，
后面还有绩效、劳动关系，
和……人力资源规划~
但是呢，这种分类方式特别教条化，
怎么可能有人只做薪酬，
有人只做招聘呢？
比如你做招聘的，
肯定得了解候选人薪资呀，
也得了解绩效嘛。
所以后来就有人把六大模块这个理论完全抛开，
提出了全新的三支柱理论。”

“那是哪三个支柱呢？”

“第一个就是HRBP。
第二个是SSC，Share Service Center，
SSC处理的都是一般性事务。
还有个叫做COE，Center Of Expert，
就人力资源专家，
你可以想像那些讲师，
专门做培训、招聘、绩效的。”

Lirian好奇地问：
“那是不是说比如‘我去当个小HR’，
这里的小HR一般指的是SSC？”

“嗯是的，世界上大部分HR都可以算是SSC。
在一个大的公司里面，
这部分HR就会专门来处理杂活，
这个类型的HR其实入门门槛很低。”

“那假如我要当HRBP，
是不是我也得从SSC做起？”

“这不一定。
假如你想当HRBP，
最有效的其实是你本来就是业务部门的人。
比如我以前是写代码的，
但我觉得哎呀写代码太吃力。
我会写，但是我写的不好，
于是我就去当HR。（Lirian笑）
然后我就去学了HR的课，
考了证书，
又做了几年招聘，
然后我再跑到一家公司去当研发部的HRBP了。
通常HRBP对资历要求比较高。
这种呢就是属于你从业务部门，
直接转去做HR，
那么你的优势会非常大，
但是事实上比较少的人会选择这么做。
我Manager Tina就是其中一个，
她以前是做销售卖ERP软件的，
所以她后来去当猎头做招聘就很有优势，
再后来她就当HR了。”

Lirian对业务部门表示了疑惑：
“什么部门算业务部门啊？”

Mia给出了定义：
“业务部门就是能给公司带来直接盈利的部门。”

“喔！比如销售！”

“对的，还有产品、售后支持部啊。
当然这种已经算有点偏的了。”

“技术部呢？”

“技术部也算啊~”

Lirian想起他们经常采购手机什么的，
表示很惭愧：
“但我感觉我们净给公司花钱了……”

“但是你们是生产出产品的人啊。
长远来看你们为公司生产了价值，
而盈利了。
像HR部门啊，行政啊，财务啊就不算业务部门。”

Lirian感慨道：
“那感觉跨界的是有优势啊”

“对，这种就是人力资源部门里不是科班出身的。
还有一种就是正正经经的，
大学也是学人力资源专业的，
然后从SSC，
做到了HR Specialist，
到HRBP，
一步一步往上做到Expert也是有的。”

听完了这一段，
Lirian对HRBP是什么大概有了点了解，
他又问了：
“那HRBP究竟会做什么呢？”

“这个呢，分很多种情况，
比如说十五年工作经验以上的HR吧。
就像我们老大，
他经常要开会，
那他都开些什么会呢？”

“是啊，都开些什么呢？”

“实际上这个层级的HR，
很多是和老板一起参与公司战略规划。
比如说Team Leader有一个目标，
然后HRBP就会说从人力资源的角度，
从人才配置的角度去帮助他实现这个目标。
特别是团队里出现了一些问题的情况，
就需要HRBP的建议，
像活特别多，干不完要招人；
或者是竞争对手一直在跟我们抢人这种。”

“呃，等等。
这么听来我觉得HRBP也不是所有情况都适用的吧？
比如说万一有人不信这套理念，
万一Leader认为业务部门的事情，
就应该业务部门自己解决。
当然了从HR的角度来说，
肯定是他没认识到HR的重要性，
但感觉也会有很多公司都是这样没有HRBP的吧。”

“会啊，初创型企业就是这样，
大公司里一般才有专门职位。
小规模的公司里这些活其实被经理啦，
主管啦，或者是部门的HR给分摊掉了。
但不要忘了，
这个时候业务部门的负责人，
他其实是自己在承担这一部分的角色。”

“科学。
要这么定义的话，
的确是谁干这部分活，
谁就承担了HRBP的角色了。”

“对的。”

“那我来复述一下我对HRBP的理解吧？”

Mia一摊手：
“请开始你的表演。”

Lirian总结了三点：“

首先HRBP广义上是一个角色，狭义上也可以是个职位。
然后HRBP存在的作用就是帮业务部门处理战略上的事情。
其次因为要帮业务部门的忙，所以假如他是懂业务出身，他是有一定优势的。

”

Mia又补充了一下：
“HRBP就是帮业务部门解决痛点问题的，
假如他是业务部门出身会有非常大的优势。
因为部门的老板会很容易被他说服。
要不然假如说HRBP从来没写过代码，
技术部门的leader可能就会想：
‘你又不懂，凭什么指挥我啊’…”

“嗯是啊。
那感觉HRBP做的厉害了以后，
下一步就直接当高层管理了？”

“是有这个可能性，
但是其实很小。
基本上比起其他部门，
一个HRBP很难成为CEO，
顶多就当一个HR部门的头头算到顶了。”

“喔，是这样啊。”

Mia又想到了点什么，
补充道：
“我们刚才说的，
都是真正的HRBP干的事情。
但事实是现在大多数公司HRBP都干的不是这个事情。
中国这套HR体系本来就是西方引入的嘛，
所以很多地方都变味了，
有些HRBP一开始又做招聘又做培训，
出了任何问题都要你解决。
这种HRBP就变成了每个团队的专用HR的感觉。”

“噢，
所以正常来说就HRBP可以接活，
但是杂活呢，就分给SSC。
太专业的活，可以丢给Expert。”

“没错，”
Mia通过了Lirian的答案，
突然又想考考他，
又问道：
“那你觉得HRM，就是HR经理和HRBP有什么区别呢？”

Lirian想了想，说：
“我感觉这两个不是一个维度上的吧。
HRBP感觉是三支柱里的一个角色，
HRM感觉更多是职位高低的感觉，
比如小HR，普通HR和HR经理这种。”

“差不多吧。
他们之间很大的差别是，
HRBP不会去制定公司的规章制度啊整套体系啊什么的，
因为他是针对特定的团队特定的业务。
但HRM就有这个责任，
去制定整套的规章制度。
比如假如公司要上市了，
老板需要有人来帮他制定完整的薪酬福利制度啊，
绩效考核制度啊，
这时候他需要的就是HRM，
而不是HRBP了。”

Lirian学到了不少，
赶快表现出恍然大悟的样子：
“学到了！”

Mia喝了口水，
总结了下陈词：
“反正我觉得最高级的HRBP，
就是站在老板的角度上想问题。
不过这样也满亏的，
拿着HR的钱，
做着老板的事情。”

Lirian笑道：
“不过假如我是老板，
我肯定很喜欢你这样的员工。
假如我的每个员工都有ownership，
都像老板一样思考问题，
那我的公司一定是个伟大的公司。”

Markdown

喝了点水，
歇了歇以后，
Mia问Lirian：
“那你上次要跟我说的Markdown呢？
那是什么？”

Lirian再次表示很惭愧：
“我感觉这个两三句话就说完了…”

“说嘛说嘛~”

“Markdown其实就是一种写文章的语法，
就像Word文件里指定了哪些字是标题，
哪些字是加粗的语法一样。
用Markdown来写文章可以让你更好地控制格式。”

“啊？说完了？”

“……说完了啊……”

Mia感觉被两三句话就打发了，
很不服，于是继续问道：
“那上次看你用有道云笔记写东西，
为什么左右有一黑一白两个屏幕啊？”

“喔，那个右边是预览页面。”
Lirian想了想，
详细地解释道：
“要讲Markdown，
我先来讲下Markup。
Markdown这个名字呢，
其实一开始是跟Markup针锋相对的。
Markup就是网页显示字体用的那种语法，
Microsoft Word用的也可以算是一种Markup。
Markup所宣扬的是WYSIWYG：
What You See Is What You Get，
中文翻译是所见即所得。
比如说我们要加粗一个字体，
我们就选中字体加粗一下。
但是这样有一个问题，
就是WYCSYCG：
What You Can’t See You Can’t Get，
格式的表现能力就一眼可见的那么多。
假如我想做到同样的文字，
在不同的环境下呈现不同的效果，
就不行了。
所以我们就有了Markdown。”

Mia听得一脸懵逼，
Lirian就拿了台电脑开始展示起来了：
“比如说Markdown这种语法，
我们写文章可以这么写”

# 这是大标题

## 这是二标题

想**加粗**字体要在字体两边各加两个星号，*斜体两边就只加一个星号*。

引用别人的话可以加反引号，`像这样子`。

引用鲁迅的话就可以在行首加大于号：

> 网上的人都瞎编我的名言 —— 鲁迅

1. 可以用数字来表示序号
2. 就像这样

* 也可以表示列表
* 就像这样

上面这段Markdown呈现出来会长这个样子：

这是大标题

这是二标题

想加粗字体要在字体两边各加两个星号，斜体两边就只加一个星号。

引用别人的话可以加反引号，像这样子。

引用鲁迅的话就可以在行首加大于号：

网上的人都瞎编我的名言 —— 鲁迅

可以用数字来表示序号
就像这样

也可以表示列表
就像这样

看完这段展示以后，
Mia表示：
“我感觉这跟你们写程序很像啊，
要记很多种东西，
而且写出来还要渲染，
感觉很麻烦啊。”

Lirian解释道：
“Markdown里，
常用的语法也就大概10种左右吧。
这个很容易学的。
而且用Markdown可以把所有的富文本转换成纯文本，
纯文本就没有在不同的电脑上，
呈现的效果不一样的问题啦。”

Mia想了想，
最后问道：
“那为什么云笔记要专门支持Markdown啊？
感觉这个功能就是给程序员设计的…”

Lirian：
“我也不知道…”

一种轻量级的Http加密方式：Hawk

Sat, 18 Mar 2017 23:55:18 +0000

这是一篇关于Hawk的简短介绍。

什么是Hawk

Hawk是一种轻量级的Http加密方式，
这里的轻量级是针对于OAuth / Digest这种加密方式而言。
Hawk主要防范的是中间人攻击，
它基于服务器和客户端共有的秘钥，
在时间戳的基础上对请求加密，
生成互相匹配的特征码。

Hawk的好处是整个加密的过程对计算能力要求不高，
用到的也是简单的sha256算法。
而且它可以只针对单个请求加密，
所以应用场景十分灵活。

在一个典型的Hawk应用场景中，
客户端首先通过某种方式跟服务端通信，
获取秘钥。
在之后的Http请求中，
客户端对请求采用Hawk加密，
并且把基本信息放在Http Header里。
服务器收到请求以后，
采用同样的方式进行加密比对，
假如两边都对上了，
则是一个合法请求。
否则返回401 Unauthorized

加密算法

Hawk协议规定的加密方式如下：

这是一个样例的HTTP GET请求：

GET https://example.com:8000/resource/1?b=1&a=2

要通过Hawk验证，
我们会把请求的特征用换行符拼接成如下格式，
最后再用HMAC sha256进行加密：

hawk.1.header
1353832234
j4h3g2
GET
/resource/1?b=1&a=2
example.com
8000

some-app-ext-data

其中hawk.1.header是表示用version为1的hawk来加密header，
1353832234是unix timestamp，
j4h3g2是客户端生成的随机字符串，
GET是请求类型，
/resource/1?b=1&a=2是请求的query，
example.com和8000分别是host和port，
而some-app-ext-data是约定好要验证的额外内容（可为空）。
上面这段字符串是大小写敏感，空格敏感且换行敏感的。

假如说我们的秘钥是werxhqb98rpaxn39848xrunpaw3489ruxnpa98w4rxn，
则上面的样例请求经过HMAC sha256加密后的特征码会是6R4rV5iE+NPoym+WwjeHzjAGXUtLNIxmo1vpMofpLAE=

最后我们把基本信息加入Http Header里，
请求就会变成这样子：

GET https://example.com:8000/resource/1?b=1&a=2
Authorization: Hawk id="dh37fgj492je", ts="1353832234", nonce="j4h3g2", ext="some-app-ext-data", mac="6R4rV5iE+NPoym+WwjeHzjAGXUtLNIxmo1vpMofpLAE="

服务器端拿到HttpHeader.Authorization以后进行加密比对即可。

其它事项

Hawk提供Payload Validation，协议中指定的加密方式是sha256，与header的加密方式HMAC sha256不一样。
假如客户端和服务器的Timestamp不一样，服务器应当返回Timestamp，由客户端计算时间差后再次请求。
具体使用中可恰当魔改Hawk请求，比如增加对id的验证等。

HR就讨厌我们这样的技术，今年一个offer都没发

Wed, 08 Mar 2017 20:44:40 +0000

还好我司HR人美心善，任劳任怨……

面试套路

年后的求职市场逐渐活跃了起来，
直观感受就是收到的简历比年前要多不少，
于是最近基本上每天我们都有面试。

我司目前一共有三个后端工程师：
津铭，周丞，我。

我们面试的套路是电话面试 - 到场面试（三轮） - 发offer。
这里的到场面试（三轮）是指我们一共有三轮到面，
而不是提供三轮接送。

不过前几天面了个广州的小兄弟，
觉得他还蛮不错的，
谢老板表示只要人厉害的话，来回路费都可以报了。

嗯，接下来就需要他证明自己是不是厉害的人了。

面试标准

其实我们的面试标准不高。
但因为上一句我用了其实两个字，
说明我们的面试标准其实也不低。

之前一次有一个前端工程师来面试，
算法题一题都没答出来，
实现题答得也不是特别好。
但是我们一致觉得这个候选人
大学四年学的是物理，毕业以后才写前端的
能有这个水平很不错，
而且浑身散发着一种学习技术使我快乐的光芒，
很让人喜欢。
于是我们发了offer，
候选人选择去了小红书…/(ㄒoㄒ)/~~

还有一次一个候选人来面试，
一路顺利地过到了我司CEO谢老板的当面面试。
谢老板是做技术的，
所以跟工程师很容易聊到一块去，
他跟候选人聊嗨了以后，
他问候选人：你为什么想到创业公司工作啊？
候选人表示很激动，
回答道：因为我的梦想就是创业啊，我想看看外面的创业公司是怎么做的，然后学了成套技术以后，我就可以自己去创业了！
当时谢老板就卧槽了。

我司技术

我司技术邮箱组有两个，
一个是yanfa@kezaihui.com，
研发部，很科学。
另外一个是llk@kezaihui.com，
这个邮箱嘛，
御姐控表示很淡定。

我司技术团队目前有10个人：
一个CEO，两个移动端，三个后端，四个前端。
类比于建筑行业就是：
一个包工头，两个推车工，三个水泥工，四个砌砖工。

因为人少，所以虽然说是前后端分离，
但是干的活交叉性很强，
后端们也会热情地参与像<如何评价真阿当的文章：《2016年前端技术观察》？>这样的热闹讨论中。
（主要是吃瓜）

还有一次吃饭的时候，产品经理Allen来问问题，
说数据库里我们主动营销的有效时间是哪个字段啊？
（没错我们产品经理也要知道数据库的表结构…）
津铭（后端）表示懵逼，有点忘了要看看代码，
然后靖哥哥（前端）说主动营销是ManualActivity，
场面顿时有点尴尬…

后端面试

年前谢老板表示我们今年工程师的quota是30个，
招满就不招了。
于是最近在金三银四的招聘季里，
我们每天都在勤劳地面试…

但是后端范围实在是太广了，
两个同为后端工程师的人，
工作内容不一定有很多交集。
前几天还面了个Oracle的兄弟，
我问他：你们前后端怎么通讯的？
他说：Oracle自己做的WebService
我：……那，你们用的什么框架？
他说：Java，我们Oracle自己写的一套…
我：……那，数据库呢？呃，Oracle？
他：对…
我不甘心：MySQL和Redis用么？
他：不用……

我跟津铭前几天在地铁上还调侃道：
假如我们面试是面写SQL语句的话，估计Allen能过，谢老板就会挂了……

于是种种原因综合在一起，
我们今年后端一个offer都没能发出去…
叹气

面试是双向选择的事情，
双向选择都是看缘分的，
缘分需要等待，
我们就只好继续等待了。

其它

我这篇文章是发在公众号和博客上的，
有可能你是在遥远的地方，
或者遥远的时间后看到的。
但是假如你对我司的岗位有兴趣，
非常欢迎直接投递简历，
或者跟我聊聊。

作为一个工程师，
我十分喜欢现在的工作，
并且我想把这个机会介绍给你 :)
而且我司除了研发，
还有产品/运营/销售等很不错的岗位噢。

XYZ问题

Wed, 22 Feb 2017 22:22:16 +0000

有的时候我们想解决的是X问题，
但是我们却纠结于Y问题，
最后却陷入了Z问题的陷阱里。

简单的XYZ问题

大部分时候，
我们的大脑会线性地思考问题，
有的时候我们想的越多，
反而容易陷入问题的陷阱里。

比如我需要一把指甲刀。
前天指甲刀还在房间桌子上，但我妈昨天刚整理过桌子。
我记得我妈好像把东西都放书房抽屉里了。
但是书房有好几个抽屉，我想弄清楚指甲刀在哪。
于是我问我妈：书房的抽屉里都有些什么啊?

在这个里，
用XYZ问题去归纳的话，
X问题就是指甲刀在哪，
但我问出的Z问题却是抽屉里都有什么。

当然了，
这个例子本身也浅显极端，
我妈很容易看出只要脑袋好用一些，
直接问指甲刀在哪就行了。

但很多时候问题都没那么简单。

真实的XYZ问题

我不擅长写网页，
但是每次我都想试试写网页。
大概就像那种不能吃辣，
但还是要吃辣的人一样。
这种情况下，我就很容易陷入XYZ问题中。

比如我需要写一个打字机效果出来，
根据命令行编程的经验，
我就觉得打字机效果大概可以等同于每0.5秒更新一次内容，
我又觉得这个大概就等同于更新内容，等0.5秒再更新，
于是我搜索JavaScript sleep 0.5 second。

/(ㄒoㄒ)/
很可惜，
这样得到的解决方案会跟我想要的相差很远。

所以解决XYZ问题最好的办法就是：
理清思路，找到X问题，直接解决它。

在这个JavaScript的例子里，
我们的X问题其实是JavaScript typewriter effect
（用这个去搜索就能找到很多现成方案了）

语文老师说要写作文总结

俗话说话粗理不粗，理粗情意重。

以后我们遇到问题的时候，
也可以想一想：

我们的X问题是什么？
我们有没有陷入Y问题的坑里？
解决Z问题有助于解决X问题吗？

用GitHub托管静态HTML页面

Fri, 03 Feb 2017 21:59:54 +0000

这是一篇入门级的技术文章，
教你怎么在GitHub上托管静态的HTML页面。

GitHub项目主页

GitHub有个设定，
就是每个项目的gh-pages分支可以通过user-domain/项目名来访问。

比如以前我把一些常用的js/css库放到我的static项目下(LKI/static)，
该项目下gh-pages分支的index.html就可以直接通过lki.github.io/static访问。

GitHub的这个设定本意是让每个项目都有自己的主页来展示，
不过我们也可以借用这个设定来托管静态HTML页面。

托管静态页面

托管页面的大概步骤如下：

拥有自己的GitHub账号
在GitHub上建立一个目录(Create new repository)
用git创造该项目下建立gh-pages分支，提交一个index.html文件

第3步的命令行版本大概如下：

$ cd /Users/liriansu/new-repo
$ git init # 初始化git目录
$ git checkout -b gh-pages # 新建gh-pages分支，并切换过去
# 跑完上一条命令后，把你的index.html文件放到new-repo文件夹里
$ git add index.html # 告诉git说index.html要提交了
$ git commit -m "add index.html" # 提交index.html
$ git remote add origin https://github.com/<username>/<repository>
$ git push -u origin gh-pages # 推到GitHub服务器上

然后我们就可以在https://<username>.github.io/<repository>上看到刚提交上去的index.html了。
最后假如你希望在GitHub上搭建个人博客，
可以参照我的搭建方案

最精简的程序语言：Iota

Tue, 24 Jan 2017 13:07:50 +0000

这门语言，只有两个保留字(reserved keyword)

各种语言的reserved keyword

今天逛SO的时候发现了这样一个问题：
Reserved keywords count by programming language?

各语言的保留字数目按从大到小的量大概如下：

| ANSI COBOL 85 | 357 |
| JavaScript | 180 |
| C# | 102 |
| Java | 50 |
| Python 3.x | 33 |
| C | 32 |
| Go | 25 |
| Brainfuck | 8 |
| iota | 2 |

嗯，Python的保留字果然是少，
怪不得有个笑话是说Python其实是“可执行的伪代码”

python is executable pseudocode, while perl is executable line noise.

不过等等，这个iota是什么语言？
居然只要两个保留字就可以实现图灵完备了？

Iota 程序语言

虽然这里我们说Iota是程序语言，
但其实真要用Iota写可执行的脚本程序还是没那么简单的。
这里的“程序语言”更大意义上是计算机科学里的图灵完备的解决可计算问题的概念，
那么首先我们来看Iota的设计概念：

Iota on wikipedia

呃，上面那个页面其实是希腊字母里的Iota ι
下面这才是iota程序语言：

Iota and Jot

wiki上很好地介绍了iota，大概意思（也就是我消化过以后）：
相对于知名的lambda calculus和SKI combinator calculus来说，
Iota和Jot是非常精简的Formal System，
它们的设计初衷就是用尽量少的算子来完成图灵完备的语言。
简单来说iota只有两个保留字，一个是 *, 一个是i，
*会结合后面两个iota表达式，而i会接受表达式x，返回xSK。

看完上面一大段可能已经有点晕乎了，
那么换个角度，我们想象一下iota是怎么被创造出来的吧。

一群人聚在一起，
当时已经有了图灵理论，
有了lambda算子，
有了functional programming，
于是有人提了个问题：
最精简的图灵完备的语言是什么？
于是Chris Barker站在一系列已有理论的基础上，
发明了iota这门语言。

SKI 算子

SKI就是iota发明路上一个很重要的巨人肩膀。
SKI一共定义了三个算子，分别是S, K, I
:) 这名字听起来十分简单粗暴，我很喜欢。
规则如下：

SKI以带括号表达式的形式呈现，可以把xy = z简单理解为函数x接受参数y返回值z
I接受一个参数，并返回它，即有Ix = x
K接受两个参数，并返回第一个参数，即有Kxy = x
S接受三个参数，返回一三参数对二三参数的操作结果，即有Sxyz = xz(yz)

根据以上玄妙的定义，神奇的事情发生了 :)
SKI实际上只需要S和K算子，I算子可以用SKK表示 :

 SKKx
= Kx(Kx) # 根据Sxyz = xz(yz)
= x # 根据Kxy = x

而通过SKI，我们可以做很多的事情：

递归
取反
布尔逻辑

以上例子可以去维基看原文: SKI combinator calculus

回到iota

在SKI之后，Chris Barker提出了iota算子，
有 ix = xSK

所以可以推出：

 ii
= iSK
= SSKK
= SK(KK)
= SKK <=> I
i(iI)
= i(ISK)
= i(SK)
= SKSK
= KK(SK)
= K
iK
= KSK
= S

:) 瞧，这就是逻辑的魅力。
我们通过定义一系列很小的基石，
就能处理整个大厦。

总而言之，iota在SKI的基础上定义了一个关键的算子，
再加上*字符做到程序化地表示，
从而实现了最精简的程序语言这一目标。

如何在Mac OSX中用Finder打开特定Path

Mon, 26 Dec 2016 17:01:38 +0000

今天终于学到了这个很有用的知识，
感觉有必要记下来…

两个方法：

在Terminal中输入open /Users
在Finder中敲Command + Shift + G，然后输入/Users

对Mac系统不熟悉的乡下人伤不起啊…

disqus不稳定，于是我开始用commentit了

Thu, 22 Dec 2016 20:20:07 +0000

挂在GitHub Pages上的静态博客的评论总是个蛋疼的问题，
我以前一直都是用disqus的，
但是它总是处于墙于被墙的边缘…

因为~~自己感觉没那个必要从头搭建博客服务器~~懒，于是我直接采用了GitHub Pages。
但是由于GitHub Pages是静态页面，所以评论系统就成了问题。
于是研究了一番以后我用了disqus的第三方评论。

disqus的便利之处在于构建简单，
我只要去注册一下，加一个comments.template就可以自动展开成评论页面了。
但是出于种种原因disqus对墙内用户支持的不好。

而且我又不想用多说，那个看起来无比蠢……

直到我最近发现了一款黑科技：Comm(ent|it)。
一句话概括它静态评论的原理是：所有的评论会变成Git Commit，push到你的Repository里面去。

雾草！
感觉很爽！

而且其实它的template配置和disqus的一样简单。
补充：我们还要在commentit的配置页面配一下允许直接提交到master :)

:) 所以是时候在本页面下面评论，
以成为本博客GitHub项目的Contributor啦~

用vundle来管理vim插件

Sun, 18 Dec 2016 02:22:16 +0000

今天把vim插件管理器换成了Vundle，
之前我一直用的是pathogen。

Vim配置

其实我是在实习以后才开始用Vim的，
当时Justin直接把他的vim配置给我clone了一份。
直接用现成的配置大大减缓了Vim的学习曲线，
而且很快就可以上手用起来了。
直到现在，我也觉得上手Vim的正确姿势就是找个大腿的配置。

后来Vim稍微用的多了一些以后，
我开始尝试自己手动改vimrc来改设置。
改代码的基础就是看代码/学习代码，
于是我了解到了pathogen，
一个快速添加插件的Vim插件…

pathogen

pathogen的优点就是小巧和直白：

你只需要添加autoload文件夹，
配置pathogen的载入，
就可以自己在预设好的插件目录下任意增删插件了。

然而实际使用中有几个蛋疼之处：

为了方便，我一般会用git submodule来添加插件。
git submodule不仅有着屎一样的用法，
它的commit还是固定的，
于是我经常要手动去更新插件版本。
因为用了git submodule，删除插件也变得麻烦了。
pathogen主要是Tim Pope写的，
而这个项目一年内只有三次更新…
一点也不活跃。

出于灵活度/便携度/活跃度的考虑，
我决定换个包管理器。

Vundle

于是我就想到了Vundle，
一个看起来很正式的Vim插件管理器。
它的配置其实也比较简单：

本地克隆Vundle包（可用git submodule），
配置vimrc，然后在vimrc内写入插件名。

不过第一次用命令vim +PluginInstall +qall加载插件的过程可能比较慢。

现在的配置

于是鼓捣了一下，
成功从pathogen换成了vundle。
dotvim地址在github上。

题外话：
第一次了解到Vundle的时候，
我总感觉这有种浓浓的Emacs包管理山寨风，
于是当时我根本没考虑Vundle…
所以说技术品味不能充当唯一技术评判标准呀~

后端工程师技能树

Fri, 16 Dec 2016 23:33:08 +0000

我最近打算点专精天赋后端工程师，
于是先整理一份后端的技能树，
然后努力攒天赋点把它给点满。

全栈

前几天我和Joyce聊天讲到“我想写个后端技能树/练级攻略”，
她疑惑地问我：“你觉得各个端之间要分那么开么？”
我想了想，说：“呃。。。”（其实也不知道说什么）

其实关于全栈的争论一直都有，每种意见都有科学之处：

有人认为全栈适合小团队，大团队更需要细化分工。
又或者全栈是个伪命题，因为光一样技术学精学通就要花很大功夫了。
的确，在分工明确的情况下，各项全能的人才反倒是被浪费了，
更不用说这样的人本来就少。

也有支持向全栈发展的人认为新人适合专精一门，牛人始终是全能的。
以及全栈指的不是语言，而是更基础的知识体系和综合能力。

我其实是蛮羡慕全栈们的，而且我也希望以后某日化身为全栈。
但我总觉得目前的自己还是太菜了，连一门技艺也不精通，更别提全栈了。
而且武侠小说里面说得好：大道相通。
也就是说我学好了一门技艺，想再去理解别的会更有经验，
即使达不到各项全能，说不定也能做到一精多专呢 :wink:

嘿嘿，这么说来，写代码学技术和练武还是蛮像的。
就好像程序员练级攻略一样，打怪升级穿女装嘛~

后端技能树

程序基础
- 算法和数据结构
- 语言基础
- 框架和库
- 抽象逻辑能力
- 英语能力
- 代码风格
- debug
计算机网络
- 网络协议
- 服务器
- 代理服务器
- 网络安全
- 权限
- RESTful
数据与数据库
- 关系型数据库
- 非关系型数据库
- 性能优化
- 数据挖掘
- CAP
团队协作
- 沟通能力
- 版本控制
- 任务管理
- 项目管理
- 开源项目
- 装逼与装菜逼
架构设计
- 高拓展
- 高并发
- 高可用
- 高血压（并不）
价值观
- 学习意愿
- 热爱技术
- 心态开放

这是我心中的技能树，最后一节严格意义上不是技能树，
但我也觉得这些品质对一个后端工程师是有益的。
欢迎各种建议/评论 :)

git新手教程

Mon, 19 Sep 2016 16:04:00 +0000

这是一篇针对技术小白们的Git科普文章。
本文主要介绍版本控制工具Git的基本概念，
以及init,status,add,commit,reset,log几个基本命令。

什么是Git

在十多年前，有好多程序员一起开发Linux系统。
这么多人一起写一个软件，他们就需要一个好的软件来
控制代码的版本/回滚代码/并行开发。
最开始他们是用的一个现成的软件叫BitKeeper，
但是后来BitKeeper居然想收费！于是他们就开发出了Git…

没错，Git就是一个由程序员自己写的，
写给程序员自己用的，用来管理写程序的工具。
本文想做的就是把Git这个程序员用的工具
介绍给不懂写代码，但是要写文档，改文档的同学。

（所以本文的具体栗子是在Windows系统下进行）

什么是版本控制

举个栗子：
今天要写毕业论文，我打开了Microsoft Word，写完了第一章。
但我突然有一个更好的想法，我决定重写第一章。
于是我按下了撤销按钮，Word文档回滚到了最开始的地方。
我坐了三分钟，我发现其实还是我之前的第一章写的比较好。
于是我按下了重复按钮，Word文档又回滚到了我写完第一章的时候了。

上面的栗子，其实就是一个典型的版本控制场景。
而Git作为版本控制的工具，做的就是文件级别的版本控制。

接下来我们直接来试用Git。

安装Git

首先我们到Git的官方网站（英文）
去下载最新的windows版本的git：
（当你用浏览器打开这个网站的时候，就应该有下载框弹出来了）

下载地址：https://git-scm.com/download/win

下载完毕以后打开，大部分设定用默认的就行了，
几个关键选项图示如下：

安装选项：

安装命令：

换行符操作：

安装完毕后我们在任意菜单右键，
应该就可以看到“Git Bash Here”的选项。
并且打开以后我们输入git version
可以查看到git版本号信息，
这就说明我们安装成功了。

$ git version
git version 2.9.0.windows.1
（具体版本可能会随时间变化，但这并不重要）

新手上路

打开Git Bash

git是一个命令行工具。
（虽然也有图形界面，但那个太蠢了，
我们还是学习更好用的敲命令吧）

首先我们打开一个文件夹，
比如我打开的是D:\git-first-lesson\XML这个文件夹，
然后右键菜单 -> Git Bash Here，
就打开了一个这样的Git Bash：

再顺便说一下几个基本的命令：

ls: list的简写，可以查看当前文件夹下有哪些文件（夹）
cd: ChangeDirectory，可以更换目录。cd ..就是回到上一层目录

Git目录

想了解一个目录的状态，就使用git status命令。
我们可以试着跑一下这个命令，但是Git会报这样的错误：

$ git status
fatal: Not a git repository (or any of the parent directories): .git

这个错误的字面意思是“错误：你并没有把当前目录（或者任何父目录纳入git版本控制）”。

所以为了将一个文件夹纳入版本控制，我们要使用git init命令:

$ git init
Initialized empty Git repository in D:/git-first-lesson/XML/.git/

提示信息表示git已经初始化完成。
这个过程实际上是git在当前目录新建了一个**.git**文件夹：

然后我们再跑git status就可以查看到当前目录状态了：

控制文件

在我们初始化完git以后，git默认是把所有文件帮我们找出来的。
但是假如我们并不希望修改.wmv音频文件，.bak备份文件，Data数据文件夹怎么办？
或者假如我们只想版本控制.xml文件该怎么做呢？

git在这里给我们留了一个控制文件，叫**.gitignore**文件。
我们可以右键 -> 新建文本文件 -> 重命名为.gitignore或者直接在git-bash里面跑touch .gitignore:

假如我们想无视wmv文件，bak文件和Data文件夹，我们修改.gitignore内容为：

*.wmv
*.bak
Data\

假如我们只想控制xml文件，我们可以修改为：

*
!*/
!.gitignore
!*.xml

然后我们可以再跑一次git status查看文件夹状态：
（在本例中我的.gitignore只控制了xml文件）

设置/查看断点

Git最激动人心的地方到了：
有了前面的准备工作，
我们现在已经可以设置断点，
并且再未来随时回滚到任意断点了！

我们直接看看怎么设置断点（Commit）：

使用git add .来记录当前目录的改动。
使用git commit -m <commit_message>来设置断点。

比如我们输入git add .和git commit -m "My First Commit"：

好了！断点设置成功！接下来我们可以查看我们设置的断点：

我们可以使用git log来查看断点，或者是git log --oneline来查看断点的简略信息。

比如这样子：

查看修改内容与回滚

到目前为止，我们所做的操作都不会修改当前文件夹。
我们只是将整个文件夹当前的状态纳入了版本控制。

接下来我们要做的就是改动文件了。
比如我们稍微改动了Struture\recurse.xml这个文件。

使用git diff可以查看当前文本和上一版本的区别。

使用git reset --hard HEAD可以回到上一个断点。

总结

在本篇新手教程中，我们稍微介绍了版本控制和Git。
在安装完Git以后，我们接触到了以下命令：

命令	说明
`git version`	显示Git版本
`ls`	列出当前文件夹内文件
`cd data`	更改目录（进入data目录）
`cd ..`	回到上一层目录
`git status`	查看Git状态
`git init`	初始化（使当前文件夹纳入版本控制）
`touch .gitignore`	新建.gitignore文件
`git add .`	使所有未被ignore的文件加入版本控制
`git commit -m "My first commit"`	设置断点（准确的说是生成一个提交）(commit)
`git log`	查看历史
`git log --oneline`	查看简单历史
`git diff`	查看当前文件夹状态与最近断点的区别
`git reset --hard HEAD`	回滚至上一断点

在之后的教程中，我们会更加深入地接触Git。

（完）

You can live your dream

Mon, 27 Jun 2016 23:06:13 +0000

前阵子我偶然看到了一个非常棒的关于梦想的视频

视频地址在Youtube上（需翻墙）

总之各种意义上都是很正能量的一个视频，
台词如下：

I don’t know what that dream is that you have. I don’t care how disappointing it might have been, as you’ve been working toward that dream. But that dream your holding in your mind that it’s possible that some of you already know that it’s hard. It’s not easy. It’s hard changing your life. That in the process working on your dreams you are going to incur a lot of disappointment, a lot of failure, a lot of pain. At moments when you‘re going to doubt yourself and say God why is this happening to me. I’m just trying to take care of my children, and my mother. I’m not trying to steal or rob from anybody. How does this have to happen to me?
For those of you all that have experienced some hardships don’t give up on your dream. The rough times are going to come, but they are not going to stay. They have come to pass.

Greatness is not this wonderful, esoteric, illusive god-like feature that only the special among us will ever taste. It’s something that truly exists in all of us.

It’s very important for you to believe that you are the one.
Most people they raise a family, they earn a living and then they die. They stop growing, they stop working on themselves, they stop stretching, and they stop pushing themselves. Then a lot of people like to complain but they don’t want to do anything about their situation. And most people don’t work on their dreams, why? One is because of fear, that they have fear of failure. What if things are worked out? And the fear of success, what if they do and i can’t handle it. These are not risk-takers.

You spend so much time with other people, you spend so much time trying to get people to like you. You know other people more than you know yourself. You studied them you know about them, you want to hang out like them, you want to be just like them. And you know what you’ve invested so much time on them, you don’t know who you are. I challenge you to spend time by yourself.

It’s necessary, that you get the losers out of your life, if you want to live your dream. But people who are running towards their dreams, life has a special kind of meaning.

When you become the right person, what you do is start separating yourself from other people. You begin to have a sudden uniqueness. As long as you follow on other people, as long as your being a copycat you will never ever be the best copycat in the world. But you will be the best you could be. I challenge you to define your value.

That everybody won’t see it, that everybody won’t join you, that everybody won’t have the vision. It is necessary to know that. That you are an uncommon breed.
It is necessary that you align yourself with people and attract people into your business, who are hungry. People who are unstoppable and unreasonable, people who are refusing to live life just as it is and who want more. The people that are living their dreams. are seeking winners to attach themselves to. The people that are living their dreams, are the people that know that if it’s gonna happen it’s up to them.

If you want to be more successful. If you want to have and do stuff you’ve never done before, I’m asking you to invest in you. To invest in you!

Someone’s opinion of you, does not have to become your reality. That you don’t have to go through life being a victim. And even though you face disappointments, you have to know within yourself, that I can do this, even if no one else sees it for me, I must see it for myself.

This is what I believe and I am willing to die for it. Period.

No matter how bad it is or how bad it gets, I’m going to make it.

I want to represent an idea. I want to represent possibilities.

Some of you right now, you want to go to the next level. I want a council, I want to be an Engineer, I want to be a Doctor. Listen to me. You can’t get to that level. You can’t get to that level economically where you want to be, until you start investing in your mind. You’re not reading books. I’m challenging you all to go to conference. I dare you to invest time. I dare you to be alone. I dare you to spend an hour to get to know yourself.

When you become who you are, when you become the person you are created to be, designed to be who you were designed to be. When you become an individual. What you do is take yourself and start separating yourself from other people.

I’m challenging you to get to a place where people do not like you or do not even bother you anymore. Why? Because you are not concerned about trying to make them happy. Because your trying to blow it, you’re trying to get to the next level. I need you to invest in your mind.

If you’re still talking about your dreams. If you’re still talking about your goals. But you have not done anything yet, just take the first step.

You can make your parents proud. You can make your school proud. You can touch millions of lives and the world will never be the same again because you came this way. Don’t let anybody steal your dream. Don’t let nobody steal your dream! After we face rejection and a “NO”, we have a meeting and no one shows up, or somebody said you can count on me, and they don’t come through. What if we had that type of attitude that cause repossess, nobody believes in you, you’ve lost again and again and again. The lights are cut off, but you still are looking at your dream, reviewing it everyday and saying to yourself, IT’S NOT OVER UNTIL I WIN!

You can live your dream.

URL中参数编码不正确的解决方案

Tue, 07 Jun 2016 21:29:39 +0000

说是说解决方案，其实并没有解决这个问题 :wink:

URL中参数编码不正确

最近在做Python-Scrapy的爬虫，用Tornado写了一个服务器程序，
但是遇到的问题是

Tornado无法解析URL的中文

比如说样例小程序如下：

from tornado.ioloop import IOLoop
import tornado.web as tw

class SampleHandler(tw.RequestHandler):
 def get(self, path):
 self.write(path)

app = tw.Application([(ur'/(.*)', SampleHandler)])
app.listen(8080)
IOLoop.current().start()

但是访问https://localhost:8080/浮云计算却只能得到æµ®äº�è®¡ç®�这样一坨东西…

解决方案

长话短说，这是因为URL中文解码不正确的原因导致的。
所以我们利用站长工具url编码手动替换中文访问即可：

访问https://localhost:8080/%e6%b5%ae%e4%ba%91%e8%ae%a1%e7%ae%97就可以得到浮云计算啦。

详细原因

一开始我怀疑是因为字符串没用utf8编码，
于是尝试了不同的转换方式：

self.write(str(path))
self.write(unicode(path))
self.write(path.encode('utf8'))

这些常识不是报错，就是根本没变化。

最终我找到了一个前人的经验，里面是这么讲的：

看来你是不知道在浏览器地址栏手动输入中文和在页面上一个的链接的编码处理方式是不同的。。。。
打个比方，在windows系统上，你在FF地址栏输入"https://localhost/中文.html?m=汉语"，这里的“中文”两字的编码是utf8（这一点应该是跟浏览器设置相关），而“汉语”则是gbk，跟操作系统相关（大部分中国人的windows应该都是cp936，也就是gbk）。
如果你是通过某个页面访问这个链接的，则所有字符的编码都是跟页面的编码相关。
在IE上也是一样。
所以，我觉得还是打消在浏览器地址栏输入中文这个想法吧，要不然你要解码两次，而且还要保证页面上的编码跟系统一样，不然无法保证手动输入和页面点击的兼容性。。。。

喔，原来是因为URL解码方式完全取决于浏览器和操作系统，也就是说中文有可能以GBK来编码

怪不得Python/Tornado认不出来了！

所以解决方案就是我们手动去解码一次啦~

（或者Python3 XD）

在Windows上安装pip

Wed, 18 May 2016 21:39:29 +0000

pip是python的包管理工具，在Linux上安装比较简单，
但是在Windows上安装就稍微麻烦些。

安装Python

首先我们到Python的官网下载Python。

值得注意的是Python2和Python3非常不同，
里面的差别可能有半个Java和JavaScript的差别之大。
我习惯使用的版本是Python2.7。

下载安装完以后，打开
我的电脑右键菜单>属性>高级系统设置>环境变量
设置好Path：

然后我们打开命令提示符，就可以进python的shell啦：

> python
Python 2.7.11 on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()

安装pip

我们使用get-pip.py一键安装pip，
先把它右键另存为下载到某个地方。

然后我们以管理员身份打开命令提示符，
直接用python运行该文件就可以安装pip了：

python get-pip.py

Windows上运行pip的方式是：

python -m pip
Usage:
C:\CodeEn\Python27\python.exe -m pip <command> [options]
Commands:
install Install packages.
download Download packages.
uninstall Uninstall packages.
freeze Output installed packages in requirements format.
list List installed packages.
show Show information about installed packages.
search Search PyPI for packages.
wheel Build wheels from your requirements.
hash Compute hashes of package archives.
completion A helper command used for command completion
help Show help for commands.

安装C++ for Python

Windows上很多Python库都依赖于C++ 9.0，
点击下面链接下载并安装：

Microsoft Visual C++ Compiler for Python 2.7

最后我们就可以使用python -m pip install来安装新的module啦

参考

如何用Windows命令行统计文件行数

Fri, 15 Apr 2016 22:13:15 +0000

今天要统计文件行数，可是手边恰好没有Linux环境。

Linux 统计代码行数

在 Linux 下这是一件很简单的事情：

 find . -name "*.py" | wc -l

这行语句就可以很简单地统计出当前目录下所有py后缀文件的行数了。

Windows 统计代码行数

这时我们就不能用cmd而是应当用PowerShell啦。

Powershell是Windows基于.NET开发的一个自动化配置框架。
（其实就是新版命令行）

然后我们可以输入：

 dir .\ -Recurse *.py | Get-Content | Measure-Object

我们就可以看到输出：

Count : 1253

表示当前目录下py后缀文件一共有1253行。

为什么我讨厌吸烟

Thu, 31 Mar 2016 16:27:34 +0000

这两周读完了《中国烟草的政治版图》

烟和毒品

上周的某一天，跟往常一样，上班路上全是吸烟的年轻男性。
捂着鼻子走到了公司，我觉得非常不能理解：
为什么烟不算是毒品呢？

大部分吸烟的人是做不到想戒烟就戒烟的，
而且就算是外力阻挠的情况下（家人反对，公共场合禁止），
这些烟民还是找机会吸烟。
既然这种精神上的依赖已经算得上是成瘾，
那么为什么我们不会认为香烟是毒品呢？

于是我稍微地去搜了一下，主流的观点是这样子的：

知乎上的回答

reddit上的回答

看来香烟的问题中外都有，总结下来有三点：

毒品这个词更大意义上是法律用词，在英文里drug也有药品的意思。
所以“香烟是毒品”这个说法本身不够严谨。
从久远的时候，烟草就是一个行业了，到了现在烟草行业更是发展壮大。
作为国家的一大经济来源，而且为了照顾烟民的情绪，全面禁烟是不现实的。
个人角度来看，烟瘾仅仅会伤害个人身体，不会危害社会。
酗酒会撞车，大麻会致幻，吸烟只会死得早。

中国烟草的政治版图

为了更严谨地看问题，以及努力完成今年的读书计划，
我去读了李成写的《中國煙草的政治版圖》。

这本偏论文向的书里面主要讲述了中国烟草的现状，
国家角度上吸烟可能带来的健康影响，
对中国香烟从上到下的分析，
以及从政治角度治理这些问题的建议。

整本书学术意味很浓厚，
基本没有小说性（也不应该有），
不过读起来还是津津有味，
比如里面有些数据非常引人深思：

我们都要多运动

正如作者所说，
一方面情况在变得更好，
中国烟民的比例在下降，
而且民众也自下而上地觉醒了健康的意识。
但一方面情况也不是那么好……

作者说

我的愿景

我一开始讨厌烟，完全是觉得烟味太呛人。

在庆幸家里没有人吸烟的同时，
我也逐渐觉得香烟更是一个社会问题：

对于国家，香烟产业是税收大户。
但是从公众健康来说，禁烟可以提高国民身体素质，
避免吸烟所带来的医疗支出。
对于中国社会，吸上等烟是身份的体现，而且烟本身作为礼品是普适性的。
（假如我们在所有香烟包装上印很吓人的肺癌图片…）
对于低收入烟民，一包香烟就能在精神层面上让他们满足。
（所付出的仅仅是金钱和一点点寿命。）

所以理性地说，吸烟的确有害健康，但是总有人会不在意自己的或是他人的健康。
随着社会的发展，烟草带来的问题也会逐渐暴露，
但这也为解决烟草问题提供了一个契机。

总的来说，我讨厌烟味，讨厌吸烟带来的健康问题，
我希望大家都可以活得更久。

希望世界越来越好。

Ubuntu系统X packages can be updated的解决方案

Wed, 16 Mar 2016 16:14:19 +0000

一个关于Ubuntu系统的小技巧。

x package can be updated

最近登录系统的时候，
系统老是提示

 x packages can be updated.
y updates are security updates.

噢，就像AppStore上面的小红点一样，
更新一下就好了，
于是敲下命令：

 apt-get update
apt-get upgrade

但是更新完以后，系统还是提示

 x packages can be updated.
y updates are security updates.

在查阅了资料以后才知道，
update + upgrade不能更新完所有的软件包，
还要跑一条命令：

 apt-get dist-upgrade

这个有一点点小烦人的提示就不见了。

MOTD

ubuntu开机时显示的这个Message叫
MOTD(Message of the day)，
很多公司会让系统管理员定制自己服务器的MOTD。

Ubuntu系统里，MOTD的脚本默认放在/etc/update-motd.d下，
我们所看到的x packages can be updated就是由
/etc/update-motd.d/90-updates-available这个脚本提示的。

所以我们想彻底去掉这个提示的话，
可以把/etc/update-motd.d/90-updates-available这个文件删掉（不推荐）。

同理，我们也可以定制一下自己的MOTD。

总结

Ubuntu下更新全部包命令为aptget update && apt-get upgrade && apt-get dist-upgrade.
系统一开始显示的Message叫MOTD，默认放在/etc/update-motd.d下。

创建GitHub项目主页

Tue, 15 Mar 2016 21:19:53 +0000

最近终于偶然了解了怎么给GitHub项目建主页。

GitHub Pages

GitHub Pages是一个让用户很方便托管项目网页在GitHub的服务。
比如我这个博客就是GitHub Pages建成的。

但是这样只能托管一个名为
GitHub用户名 + “.github.com"的项目(lki.github.io)

假如我还有一个项目也想用域名访问怎么办呢？

于是我机智的我用git submodule来解决了这个问题。

Git Submodule

git submodule其实是一个很蠢的解决方案：

为了保证最新的内容，父项目要随着子项目更新而更新。
这个做法其实是hack了jekyll build，感觉不是特别靠谱。
remove a git submodule实在是太痛苦了！
所以没有必要就不要加git submodule啦。

更好的解决方案

前几天在逛羡辙学姐的GitHub的时候发现了这么一条Issue

里面这么说道：

主页用 CNAME 指向 zhangwenli.com 后，ovilia.github.io 将跳转到 zhangwenli.com
其他项目 xxx 的 gh-pages 分支将会自动对应到 ovilia.github.io/xxx

喔！原来GitHub会默认地把some-repo项目的“gh-pages”分支映射到some-one.github.com/some-repo下面去。

所以我们就可以用新建分支把菜谱映射到/mymenu了。

总结

GitHub项目可以建一个gh-pages分支来映射到github.com下面的github.com/repository-name.
多看多学多试.
假如不是绝妙的hack就要追求best practice.

为什么我不招你当我的员工

Wed, 02 Mar 2016 13:41:04 +0000

匈牙利有一个叫Andor Jakab的人写了一篇很犀利的文章，
然后匈牙利网络评论就炸了。

译者说

在2011年，匈牙利有个叫Andor Jakab的人发了篇文章，
叫Tőlem ezért nem kapsz munkát（现在链接已失效）。

后来由于这篇文章影响太大，在Facebook上有上万个赞，
他就自己把文章翻译成英文，在这里：
This is why I don’t give you a job

虽然离Andor Jakab发这篇文章的时候已经有好几年了，
而且文章可能比较偏激…
但是其中讲的道理还是令人深思的。
译文如下：

为什么我不招你当我的员工

我能雇12个员工，给每个人税后760欧的工资，但是我偏不。
首先你能在我公司里的一间很棒的办公室里工作。
其次我们不做电话营销，也不是诈骗公司。
你的工作是正经活，也要求你有很高的职业素养。
你将会每天工作八小时，每周干五天。
我会合法地雇用你，帮你交足税和社保。
这样的工作我能雇12个人，但是我偏不。
我来解释为什么。

我不会雇女员工

原因很简单：女人生小孩。
另外我也没有权利问她想不想生小孩。
假如我能问，而且她回答了，
理论上她也可以欺骗我，或是后来改主意了。

别理解错了，我对女人生小孩没有任何意见。
我也是这么出生的，我的小孩也是这么出生的。
我不会招女员工是因为：当她怀孕以后，
她就有三年产假，而且我不能解雇她。
假如她要生二胎，就一共有六年的假期了。

当然，工作还是要做的，
所以在这长长的产假里，我得再招一个人替她干活。
但是我不能在她产假的时候解雇她，我也不能在她回来以后解雇她。
所以我只能把那个一直在替她干活的人给解雇掉。
而且当一个女员工度完产假以后，
法律要求我得把她的工资提升到她现在职位应有的数目上。
我还得把她产假那几年的的年假给她补上。
于是等她回来工作的时候，她还会有2到4个月的带薪年假。

我也不会雇50岁以上的员工

并不是因为我对这些最有经验的员工有意见。
我不雇他们，是因为他们很快就到了保护年龄。
然后我就被他们套住了，就像我被女员工套住了一样。
在保护年龄里，你不能解雇他们。
所以我还是得给足薪水，即使他们干的不怎么样或者马马虎虎。
我不能解雇这些被法律保护的员工，但总得有个人来把事情做好，
所以我还是得再雇一个人。
我对法律保护他们没有任何意见，但是我不会雇佣他们。

我只会雇佣25到30岁的男员工

雇佣他们其实也是很冒险的。
因为没有正当理由的话（比如我自己收入不足，或者我不喜欢他们的工作态度这些都不是正当理由），我是没有权利解雇他们的。
我直接解雇他们的话很有可能要上法庭，也很有可能是他们胜诉。
不过这个风险我能接受。

你拿到的是730欧，我却要出1572欧

| 你的税后收入 ||| 你的税前收入 ||| 我要出的钱 ||| 比值 |
|————–|||————–|||————|||——|
| € 185 ||| € 238 ||| € 306 ||| 165% |
| € 227 ||| € 306 ||| € 393 ||| 173% |
| € 322 ||| € 458 ||| € 589 ||| 183% |
| € 408 ||| € 612 ||| € 786 ||| 193% |
| € 479 ||| € 765 ||| € 982 ||| 205% |
| € 570 ||| € 917 ||| € 1178 ||| 207% |
| € 760 |||€ 1223 |||€ 1572 |||207%|
| € 950 ||| € 1529 ||| € 1965 ||| 207% |

这是根据www.nettober.com 薪水计算器得来的2011年最新的数据。
如你所见，我的公司要出1572欧才能付得起你760欧的收入。
要把这个接近两倍的比值给降下来的唯一方法是：
我付你更少的薪水。
不过我不会用更少的薪水来雇用你，
因为我觉得少于760欧的薪水很难让你活的体面。
你会感到压抑，不开心，然后影响你自己、我的公司、甚至我。
所以我不会以低于这个价格的薪水来雇佣任何人的。

只有匈牙利的法律这么蠢

上面那张图出自Deloitte。
如你所见，国家拿走了你一半多的薪水。
我付了一千五百多欧，你却只能拿到不到一半，这也太蠢了吧。
更别提那些拿着基本工资的人却跟你享受着一样好的医保。

我也认为一个35岁的员工每年应该有25天的年假。
这意味着这年假对应的一个月的工作还需要有个人来完成。
所以假如我需要12个员工的劳动的话，我得雇佣13个人来抵消假期。

尽管困难重重，我还是愿意雇佣你的

我是一个勇敢的企业家。企业家都要拥抱风险。
所以我会把我的房子卖了，住到一个租的房间里。
我希望我的房子能卖到90000欧的高价，
然后我就可以勇敢地创业。
假如最终我创业失败的话（创业好像基本上都会失败），
嗯，我会坚强地不哭的 :)

我的公司会提供让客户满意的服务，一个好的办公场所是必需的。
我会雇13个人，因为我需要12个人的劳动力（有一个是来顶年假的）。
我们14个人（算上我）将会在158平米装修良好的办公室里工作。
因为租金大概是10欧每平米，再算上每平米3.5欧的设备支出，
在办公场地上的支出就是每个月2133欧。

根据计算，我每个月的支出如下

|办公场地|2133欧|
|薪水|13 x 1572欧 = 20436欧|
|其他支出（会计、营销之类的）| 3058欧|
|共计|25627欧|

每个月支出这么大，听起来蛮吓人的对吧？
无论是淡季、旺季，夏天没什么生意的时候、圣诞节不用干什么活的时候，
无论我们盈利多少，我每个月的支出就是这么多。

平均来看，我们公司每个月顶多提供1000小时的服务。
所以为了收支平衡，我需要把服务的价格定在：
25627欧 / 1000小时 = 25欧/小时。
但收支平衡是不够的，我也需要盈利。

我不是个很贪心的人，毕竟挣钱很难。
为了保持20%左右的盈利率，我的定价将会是30欧/小时。
这意味着算上增值税就是37.5欧元每小时。
我不在乎那点零头，所以买我们服务的客户每小时要付37欧。

这37欧里面，7欧直接给了国家，剩下的30才是我们的收入。
我是个乐观的人。
我们的营销将会引爆市场，我的计划天衣无缝。
我们每个月肯定能卖掉1000小时的服务。
生意兴隆，员工们全部都努力工作，我也很满意。

这样我的公司每个月的收入就会有 1000 x 30欧 = 30000欧。

除去支出，公司的利润会有4373欧。
我会给自己发2446欧的税前工资，算上其他部分公司就要支出3144欧。
税后我能拿到1521欧，基本上是我员工的两倍。
所以再除去我的工资，公司的利润（税前）就是1229欧。
此外，公司税还要122欧，本地经营税要600欧（按公司总收入的2%收）。
最后，公司账上每个月就只剩507欧了。

这么看来我自己每个月能赚1521欧，但是别忘了，
为了开公司我把我90000欧的房子给卖了。
我还得租间房（每个月租金至少要300欧），
要不我就没地方住了…
我平时也会比较节约，不乱花钱，
我夫人也会工作赚钱。
我甚至没什么时间去花钱，
因为我会比我的员工更努力工作，
每天工作12小时，包括周末。

这样子我每个月就能存900欧，
100个月以后我就能再买个90000欧的房子。
所以我大概需要9年来回本。
9年以后我就不需要勒紧裤腰带来过日子了，
不需要付租金，也不需要存很多钱。
我可以过欧洲人的生活了。

处于这样的考虑——我希望你能理解——我并不是很想把我的房子卖了然后创业开公司。

但出于4个原因，我绝对不会这么创业

有些在小房间里非法竞争的对手提供同样的服务，但他们每小时只收9欧。
他们只收钱不记账，更别提交什么增值税了。
他们也不用负责。没有担保人，名义上他们不做任何事情，名义上他们甚至还不是一间公司。
他们不需要租办公室，请会计。
他们只需要每天工作5小时，然后就可以赚1000欧。
他们还会嘲笑我这月薪760欧的工作，因为我这的员工还得准时上班，按时按质按量完成工作，
还不能欺骗顾客（假如我的员工欺骗了顾客，就会被炒鱿鱼）
竞争对手还会污蔑我的公司。
我将会背上贪得无厌、黑心商人的骂名，
毕竟看起来别人定价9欧的服务，我却要37欧。
我会成为善良的匈牙利人民的敌人，
而我“诚实”的竞争对手，要价只不过我要价的四分之一。
很多员工来我的公司只是为了学习商业机密和抢走客户。
他们会信誓旦旦地保证“同样的服务，四分之一的价格”。
在抢走了足够多的客户资源以后，他们还会故意搞砸他们的工作，好让我提出解雇他们。
于是他们就把我告上法庭，说我非法解雇他们，然后他们就胜诉了。
同时，他们还在赚我以前辛苦谈好的客户的钱。
而且，他们还会在各大论坛注册小号，说自己以前在XX公司工作过，
那公司不仅服务很贵，而且质量也很差。
上面这些所有诉苦都没任何实际作用，没人会关心我究竟怎么样。

基本上这就是我不招员工的原因了。
而且我认为那些创业经验丰富的企业家，
也会因为这样的原因不招员工。
所以这就是为什么越来越多的人找不到工作，
于是经济越来越低迷，税收也会变少。
好的工作越来越少，社会福利越来越差。
最终我们的社会救济就会变得跟集中营一样糟糕。

只有满足这些条件，我才会招你当员工

只要我想，我随时随刻都能解雇你
假如增值税低一些，只收20%，最好是只收15%
假如国家“只”收30%的个人所得税
假如高收入不再意味着高税收
假如国家反腐有力，而不是惩罚正经公司

除非满足了这些条件，否则我是不会招你当员工的。
除非国家在各方面都剔除了腐败，我是不会创业的，也就不会提供工作机会了。

（完）

读博客和写博客

Mon, 29 Feb 2016 13:27:52 +0000

我最近把四火的唠叨里的推荐文章都看完了。

读博客

我很喜欢读别人的博客，
尤其是跟着timeline一篇一篇地往下读。

读博客的时候不仅了解到四火一开始是一个华为的软件工程师，
后来到了亚马逊。
更是看到了他在刚工作时的苦逼生活，还有办公室政治。
不长的几篇博文，
可以学习到前辈们几年的经验浓缩。

就像前阵子把shell909090的博客给读完了。
吐槽一句：shell909090的“简历”页面倒更加像“关于”页面

看着比自己更早出道工作也更厉害的前辈，
就会有种类似鸣人看着自来也的感觉：

写博客

以前我也写博客，不过更多是儿女情长的事情。
没有技术博客的积攒（当初自己也并不想积攒）。

直到去年某一天看博客的时候，看到Jeff Atwood写的一句话：

In 2004 I began this blog. I don’t mean to be overly dramatic, but it changed my life. Everything that comes after was made possible by this blog.

听起来很感慨的样子，于是顺着链接读完了他的感慨。
Jeff觉得“虽然每篇博客都不长，但是持之以恒就改变了写博客的人”。

一些链接

大舒’s wiki qiukeke.com

希望有一天我也能出现在别人的推荐链接里 :D

我的VR初体验

Sat, 27 Feb 2016 21:08:19 +0000

前阵子手机更新成了Android 6.0，
我照常到Gplay上看看有什么新App，
于是看到了一个Google Cardboard。

VR

VR，即Virtual Reality，虚拟现实。

在一些科幻电影里面，我们会看到主角头戴头盔，
进入了虚拟的却栩栩如生的世界。
又或者是主角脑后插管，
通过电流刺激脑部，
进入了虚拟的却栩栩如生的世界。

这就是VR虚拟现实。

因为本身概念上就带着一点娱乐性质，
VR这个概念近几年都在游戏界很火。
就比如前几年的体感游戏这个概念，
其实就带有半VR的性质。

Google Cardboard

[Google Cardboard][wiki-cardboard]是Google推出的VR平台。
它的神奇之处就是理论上只需要硬纸板、透镜，
就可以自行组装一个VR眼镜。

当然这是理论上，
不过实际上一副Cardboard眼镜也只要几十RMB。

这是我前几天在某宝上买的：

在放入手机以后打开VR apps，
或者是3D电影就可以直接观看了：

VR感想

廉价。
廉价意味着普及，普及就可以改变生活方式。
可以想象以后的饭桌上家长就会斥责小孩：
“吃饭就别带头盔了…”
改变。
世界上每一项新的技术都会带来改变，
从铁器到蒸汽到互联网。
VR技术还有很大的提升空间。

杂思丨《1984》读后感

Thu, 18 Feb 2016 22:12:54 +0000

看完了《1984》的第一感想就是：这本书比我想象中要短不少。

概要

《1984》的故事发生在架空的20世纪，
一个普通的男主Winston在一个政治高压的国家里发生的故事。

在一段动荡以后，世界分成了三个国家。
Winston所在的国家叫Oceania，Oceania是由the Party领导的。（原文）

the Party的领导人叫Big Brother，
整个国家到处都贴着Big Brother的大幅照片，
照片下面是一行大字：
Big Brother is watching you.

关于书的感想

看这本书实在是太有即视感了。

Big Brother.
书里面Big Brother是一个虚构的人物，他是the Party统治权力的化身。
我脑海中想象的Big Brother海报是类似于美国征兵的Sam大叔那样的，
虽然笑容和善，但是充满压迫感。
政治高压。
跟Mia介绍完这本书的简介以后，Mia很敏锐地问我：
“很像在讽刺苏联诶，这书是冷战时候出版的么？”
的确，这本书是1949年出版，冷战是1947~1991年。
合成词。
《1984》里面用了大量的合成词（至少我认为是合成的），
比如the Party对人民的三个要求：
crimestop, blackwhite, doublethink.

三个词

书里解释了一下这三个词的意思：

crimestop: 国家公民所想的应该都是美好的事物，不能有任何不好的思想。
blackwhite: 我们的敌人指鹿为马就是错的，但是我们的组织指鹿为马肯定是为了我们好。
doublethink: 有的时候一件事情是对的，但是这件事情的反面也是对的。

在书里，the Party就主要依据着这三个原则统治人民。

我觉得这是作者非常有意思的一个想法：
做到这三点，人民就不会存在不可控的想法了，
而the Party希望大家的想法都是可控的。

就像书里主角问他一个朋友：
“把大家的想法都抹杀掉，对组织有什么好处呢？”

他的朋友回答他：
“你是一个人，你会死，但是当你成为了组织的一部分时，你就永生了。
道理跟剪头发一样，虽然人失去了一部分，但是总体还是活着。
这就是权力，永生的权力。”

看到这里，我不禁想到《辛德勒的名单》里面的一段对话：
“你可以轻而易举地处决一个集中营的人，但这不是权力。
真正的权力，是你把刀架在别人脖子上时，可以说：‘我宽恕你’。
这才是真正的权力。”

最后

不知道这本书的中译是怎么翻译的呢，有机会得去看一看。ツ

我的2016书单

Mon, 15 Feb 2016 11:07:57 +0000

过年的时候有一个小契机，让我可以督促自己定下一个比往年要长的书单。

小契机

年后我在朋友圈里看到了这么一幅图：

“一个赞一本书，一年读完。”

这很棒嘛，于是我也发了这么一条状态：

很好，今年要读73本书。

这怎么可能嘛！

我的书单

其实也不是不可能，
比如把天龙八部算成八部……

毕竟不积跬步无以至千里，
我先整理了一个书单，
打算按顺序这么读下来：

1984
ANSI Common Lisp
阿加莎克里斯蒂
悲惨世界
白板编程浅谈
编程珠玑
Code Complete 2 (Eng. Edition)
Computer System Engineering
创业时，我们在知乎聊什么
触动人心 - 设计优秀的iphone应用
重新定义团队：谷歌如何工作
重构
Docker - 从入门到实践
Don’t Make me Think
Dune
代码整洁之道
芙蓉镇
鬼吹灯
Head First设计模式
红楼梦
Java核心技术
Java编程思想
金瓶梅
Learn Vimscript the Hard Way
Linux Fundamentals - A Practical Guide to Learning Linux
Lolita
龙枪传奇
龙枪编年史
穆斯林的葬礼
你一生的故事
男人来自火星女人来自金星
Programming Perl
平江
飘
算法导论
This is why i don’t give you a job
天龙八部
托马斯微积分
UTF-8: The Secret of Character Encoding
幽灵代笔
隐杀

Jekyll build fail的解决办法

Fri, 29 Jan 2016 23:24:45 +0000

我一直觉得笔记本和台式机jekyll build出来的结果不一样，
我猜想是Jekyll的版本不一致。
结果后来gem update以后，
反而jekyll build还失败了…

Jekyll build

jekyll build的结果不稳定是很难受的，
尤其每次build完以后git status看到的一大堆红色文件名。
而其实大部分都是各种HTML tag位置的差别。

我怀疑这有可能是两台机器上Jekyll的版本不同导致的，
于是我就跑了gem update以同步到最新版本。

等这个命令跑完以后，我跑jekyll build遇到的都是
jekyll build fail这样的ruby错误了。

Solution

搜了一下其实很简单，这是因为机子内同时装了多个版本的jekyll，
而他们又互相冲突所导致的错误。

（我不禁想问gem update为什么不会自动卸载旧版本？）

没错，解决方案就是我们跑一条gem cleanup卸载旧版本就可以了。
至少这个解决方案对我的问题是起效的。

Gem sources

另：有的时候gem官方源很慢，可以选择用gem sources命令更换淘宝源。
（不过淘宝源未必更新那么频繁）

$ gem sources -l
*** CURRENT SOURCES ***
https://rubygems.org/
$ gem sources -r https://rubygems.org/
https://rubygems.org/ removed from sources
$ gem sources -a https://rubygems.org/
https://rubygems.org/ added to sources

Jekyll-assume demo

Thu, 28 Jan 2016 11:06:56 +0000

For own interest, I extend a markdown rule using Jekyll.

Grammar

If a circle has a radius of {c-r} (20)cm, its circumference would be {c-c} (#c-r * 6.28)cm and its area would be {c-s} (#c-r * #c-r * 3.14)cm².

Note: For demostrating the grammer I have to add a space between ‘}’ and ‘(’.
There should be no space between ‘}’ and ‘(’.

Quick Show

If a circle has a radius of {c-r}(20)cm, its circumference would be {c-c}(#c-r * 6.28)cm and its area would be {c-s}(#c-r * #c-r * 3.14)cm².

Javascript之路

Mon, 21 Dec 2015 17:26:52 +0000

上大学的时候，有一门课是教各种Java的。
到了布置期末大作业的时候，老师大手一挥：“你们写个电商交易网站就可以了。”
我们满怀期待地问：“只要写后端？”
老师说道：“没有前端怎么叫网站？HTML, CSS, JS是每个程序员的基本素养。”

痛苦的自学之路

相对于美术，大部分程序员都更擅长数学。
我也一样。

老师布下作业以后，班里大部分人（包括我）都是看W3School自学的。
于是我们在屏幕上数格子画<div>。

很快我们意识到，假如每个人都这么折腾的话，作业就完成不了了。
于是我们组成了小团队，一部分人专门研究前端，一部分人先把逻辑给实现了。

最终在简陋的Ajax + jQuery下做完了那个项目

Bootstrap

虽然一直是网页苦手，但是由于网页其实是最简单而且最方便的展示手段（比PPT要强）
于是我默默地写些小东西练手。

对于库的利用使我_暂时_脱离了画<div>的束缚，
可以专注于内容了。
（于是我又了解了Lorem ipsum）

Free Code Camp

最近偶然发现了这个JS入门网站
不禁感慨当时为什么遇上合适的入门指南。

不过男人四十尚少年嘛，
就好像关谷说的

活到老学到老

就是这么个道理。

石头剪刀布中的求输策略

Sun, 08 Nov 2015 21:01:28 +0000

小时候七八岁，那时候还在看《读者》。
里面有篇文章讲了一下石头剪刀布中的求胜策略。

石头剪刀布

先讲一段有用的废话吧。
一般的博弈情况下，问题都会简化成一个容易判断的模型。
也就是说虽然反应快的人可以把后手出招当作必胜策略，
但是数学模型中一般都会摈弃掉这种可能性。

（所以看起来数学家会不太喜欢社会学家？）

在石头剪刀布这个模型里，规则基本上是三点：

双方同时出招，在石头、剪刀、布三个里面选一个。
石头赢剪刀，剪刀赢布，布赢石头。
假如平手就再战一局。

这种三选一循环互克的游戏，国外也有，叫Rock-Paper-Scissors

求胜策略

数学模型往往会假定对局双方都是聪明人，
显然地，在石头剪刀布中聪明人的策略就是乱出，
这样双方获胜的概率都是50%。

不过在真实情况中，两边都是普通人。
(明明刚才说过要简化模型的=_=)
所以我们需要做一个假设：

一般人不会连续两下都做出相同的选择

也就是说当他这次出的是剪刀的话，下次较大可能不会出剪刀。
所以只要下局出布就可以不输。
同理，对方出石头，下局就出剪刀；对方出布，下局就出石头。

概括地说，这样的假设条件下：
对手出什么，下局就出被它克制的

当然了，题设本身也是这个策略的弱点。
假如你的对手头很硬，一直不改变出招，
那么这个策略就会一败涂地。

实战案例

和女朋友下楼梯的时候玩起了谁猜拳赢了就走一步的游戏，
玩之前火速地想了一下：

女朋友输了不开心，赢了才开心，而且她不开心我也不能开心。
女朋友在逻辑上不会跟我计较，所以应该不会头很硬地和我勾心斗角。
女朋友她第一下喜欢出布。

嗯，于是我采取了先出石头，再出被她克制的选项
成功连败了五六局。

嗯，毕竟求胜策略这种东西，也可以反着来用嘛。

利用AUFS和Docker搭建多个私有开发环境

Wed, 21 Oct 2015 14:55:24 +0000

文章的开头先提个问题：
我们平常的工作中，一般都是怎样让每个人都拿到独立开发环境的呢？

八仙过海

比如最常见的做法：每人都有自己的电脑，爱怎么弄怎么弄，同步代码就用Git之类的。
但是这样初始化的过程很慢，要装各种软件各种配置。

于是也有的是建一个中心服务器，大家用Putty这类软件SSH上去，每个人都有自己的账号。
但是这样环境不独立，而且权限控制很麻烦（毕竟每个人都想sudo）

后来就直接分发虚拟机镜像了，每个人拿到一个10G的镜像文件，
直接Load一下，环境就起来了。
但是这样每次修改环境就要更新近10G…

反正就是八仙过海，各有神通了。
利用AUFS和Docker也可以做到给每个人独立开发环境。

AUFS

根据Google:

AuFS stands for Another Union File System. AuFS started as an implementation of UnionFS Union File System. An union filesystem takes an existing filesystem and transparently overlays it on a newer filesystem. It allows files and directories of separate filesystem to co-exist under a single roof.May 8, 2013

假设我们有一个目录如下：

$ tree
.
└── public
├── database
│   ├── dbfile1
│   └── dbfile2
└── src
├── helloworld.lisp
└── sudoku.lisp

我们希望以public目录为基础，给每个人创建一个private环境
于是我们跑几条命令：

$ mkdir change private
$ mount -t aufs -o dirs=./change:./public none ./private
$ tree
.
├── change
├── private
│   ├── database
│   │   ├── dbfile1
│   │   └── dbfile2
│   └── src
│   ├── helloworld.lisp
│   └── sudoku.lisp
└── public
├── database
│   ├── dbfile1
│   └── dbfile2
└── src
├── helloworld.lisp
└── sudoku.lisp

mount命令中，-t指定了type是aufs，-o是option
把change命令以读写权限，public目录以只读权限mount到了private里面

假设我们在private命令中新增，修改了一个文件：

$ cd private/
$ touch newfile
$ echo "Changes" > src/sudoku.lisp
$ cd ..
$ tree
.
├── change
│   ├── newfile
│   └── src
│   └── sudoku.lisp
├── private
│   ├── database
│   │   ├── dbfile1
│   │   └── dbfile2
│   ├── newfile
│   └── src
│   ├── helloworld.lisp
│   └── sudoku.lisp
└── public
├── database
│   ├── dbfile1
│   └── dbfile2
└── src
├── helloworld.lisp
└── sudoku.lisp

可以看到我们在private环境中所做的所有改动都在change中发生了！

这就相当于图层（Layer）的叠加，我们往只读的public层上叠加了一层可写的change层。
不过对于删除文件的情况要进行额外的检测

与Docker的叠加

有了上例中的mount，那和Docker就很好叠加了
利用Docker的Volume：

docker run -ti -v /tmp/docker/private:/work ubuntu /bin/bash

这样就可以把private目录作为volume映射到docker container里面的/work目录了。
剩下的就是Get good use of docker images了~

Virtual Machine, Vagrant, Docker的区别

Mon, 12 Oct 2015 12:49:55 +0000

Virtualization——虚拟化技术一直是计算机世界里面很重要的东西。
一般程序员听到这个词首先浮现出的就是Windows下面开着装着Linux系统的VMware。
而这个“装着Linux系统的VMware”就是我们口中的虚拟机（Virtual Machine）

虚拟机的主要好处是可以创建一个与主机操作系统不同的开发环境
（比如说一般的办公室都是Windows系统电脑）

但是开发的便利也会导致初始化一个这样的环境比较麻烦
而且当项目进行到一定程度，对环境本身一些变化有依赖的时候
从零开始创建虚拟机的开发环境会很繁琐
Vagrant就是一种用来解决这种繁琐的工具

Vagrant

根据官方的说法

Vagrant provides easy to configure, reproducible, and portable work environments built on top of industry-standard technology and controlled by a single consistent workflow to help maximize the productivity and flexibility of you and your team

Vagrant本身不做虚拟机的工作，而是允许用户用VMware|VirtualBox|AWS来启动虚拟机镜像，他们管这叫Provider
当然了，镜像在Vagrant这里叫Box，而且很多公司已经做好了初始化的Box在这里可以直接用
Vagrant还提供了对Box的初始化脚本（Provisioning），这些初始化脚本可以用更多的脚本工具来完成对Box的配置

所以其实相比于传统的虚拟机，Vagrant是站在巨人的肩膀上，完成了自动化。

Docker

Docker项目的目标是实现轻量级的虚拟化方案，它和Virtual Machine最大的不同是Docker容器共享操作系统的内核

所以Docker和传统虚拟机的对比是明显的：

特性	Docker	Virtual Machine
启动	秒级	分钟级
大小	一般为MB	一般为GB
性能	近原生	弱于原生
单机支持量	上千个	一般几十个
内核	共享	独立

Vagrant vs Docker

讲道理的话，这两个不应该放在一起比较，这两者的虚拟化级别并不是一个量级上的
而且这两者并不矛盾，假如你需要在Windows系统上搭载数个特定发行版的Linux系统，完全可以先用Vagrant + Virtual Machine再嵌数个Docker

硬要比较的话，假如你需要运行跨平台的虚拟，那就用Vagrant，否则，用Docker

最后再来张表对比一下吧：

特性	Virtual Machine	Vagrant	Docker
虚拟化	完全虚拟化	无	系统虚拟化
镜像管理	无	有，一般为GB	有，一般为MB
性能	弱于原生系统	弱于原生系统	接近原生系统
内核	独立	独立	共享

参考资料

VIM中小键盘失灵的解决方案(Putty)

Fri, 09 Oct 2015 15:34:16 +0000

我目前的开发环境是用Vagrant起一个虚拟机，然后用Putty连上去，用VIM做日常的开发工作。

但某一天更新了一些配置以后，我在VIM里用小键盘输入1的时候，VIM就会在前一行加了一个q字符，让我很是困惑。

后来谷歌了一下这个问题，得知只要把Putty的Application keypad mode给关了就行了。

奇怪的错误

当刚开始小键盘的输入和预期有差别的时候，其实我是很困惑的。

首先我在Bash里面小键盘一切正常，这说明我键盘没问题，应该是VIM哪里不对。

其次我按的是1，结果出来的是前一行的q，我再按一下2，出来的是前一行的r。
假如键盘没有问题，要自己在VIM里面实现一个这种“功能”，那也要加一行配置：
inoremap <Num1> <Esc>Oq

但是这也太奇怪了吧，VIM里面怎么可能把<Num1>给替换成<Esc>Oq这么奇怪的东西？

寻求答案

于是我找到了VIM wiki上的一篇解答

根据这篇解答，问题是出在Putty上。
Putty会默认启用“Application Keypad Mode”，这个选项被启用以后
所有小键盘上的按键（包括）都会输出一串按键序列：

原按键	生成序列
`<Num1>`	`<Esc>Oq`
`<Num2>`	`<Esc>Or`
`<Num3>`	`<Esc>Os`
`<Num4>`	`<Esc>Ot`
`<Num5>`	`<Esc>Ou`
`<Num6>`	`<Esc>Ov`
`<Num7>`	`<Esc>Ow`
`<Num8>`	`<Esc>Ox`
`<Num9>`	`<Esc>Oy`
`<Num0>`	`<Esc>Op`
`.`	`<Esc>On`
`/`	`<Esc>OQ`
`*`	`<Esc>OR`
`+`	`<Esc>Ol`
`-`	`<Esc>OS`
`<Enter>`	`<Esc>OM`

居然<Num1>真的变成了<Esc>Oq！

再去翻Putty关于Application keypad mode的说明:

Application Keypad mode is a way for the server to change the behaviour of the numeric keypad

唔，好吧，是服务器端决定的配置。

所以在Putty下简单的解决方案就是关掉这个模式了：

打开Putty配置
选中左边的Terminal -> Features
在"Disable application keypad mode"处打钩
选中左边的Session
保存Putty配置

这篇博客是怎么建成的

Thu, 24 Sep 2015 20:26:17 +0000

其实最开始的时候我是用LAMP在学校的IP上搭了一个个人博客，当时这么搭博客有几个很蠢的问题：

晚上11点断网，早上6点才恢复网络，所以这个“个人博客”会断网
学校把对外的80端口给封了，而域名访问默认就是80，所以校外访问博客要变成 https://cloudisdream:8080这种奇怪的模式
由于是自己的电脑做服务器，还得保证一直开着，这样始终不太好

JAVA / Servlet / Structs + Spring + Hibernate

在收了可观的小费以后，旅店老板悄悄地告诉你：每个大学的软件工程专业都会教JAVA+SSH

其实在LAMP之前，我曾经试过用课程里的Java+Servlet写过一个类微博的（个人？）网站

大概长这样子:

一边写我就一边感慨网页设计真是艰难，而且其实这个主页也是模仿当时的网易微博的

LAMP + WordPress

在前台HTML CSS JS到后台JAVA SQL都写过一遍以后，我开始意识到全栈工程师虽然听起来很美好，但是写起来实在是心太累了

那个时候和ED聊天，刚好聊到他的博客是用WordPress搭的，于是我就在自己的电脑上搭了一个服务器

虽然文章开头说了这么搭建服务器的缺点，但是其实学校还是给我们提供了一个便利：固定IP

于是我就去万网买了个域名，CNAME一下到学校IP。

但是因为实在遭不住一直开机，还要断网，后来还是抛弃掉了这个方式。

Github Pages + Jekyll

现在的博客就是最简单的GitHub Pages + Jekyll

网页放在GitHub上可以享受版本控制这个得天独厚的优势，Jekyll用的是Ruby，简单易用好上手。

从无到有搭建博客基本上就这么几步：

注册Github账号，并创建 account.github.com 这个目录
跑gem install jekyll，然后gem new my-site
修改_config.yml到自己的配置，然后在_post文件夹里面新增博客即可

Comments

博客少了评论总感觉哪里不对，因为是GitHub上的静态页面，基本上解决方案有：用多说评论，Disqus，或者是用GitHub issue来定制化评论
（我一开始还以为disqus == disquz）

综合各方面，我采用了Disqus，根据官方的说明文档

直接在Page里面插入一段Comment Code就可以了。

Enhancement

至此，基本主题的博客已全部搭建完毕

但是还有几点不足的地方：

页面最下方的Twitter图标最好要改成Weibo的（但是我还没搞懂怎么画）
要补完About界面
使用Kramdown的GFM render方式感觉还是不够好，尤其是界面上，还是GitHub Issue的Render方式看起来比较舒服

看来以后在写博客的同时，也要对网站持续进行优化才可以呀！

为什么我要写博客

Wed, 23 Sep 2015 00:00:00 +0000

我其实很喜欢看别人写的东西，技术类的、非技术类的，中文的、英文的。

很多人写文章的时候总喜欢说一句

我先抛砖引玉

但是往往他们写的都非常好

这样的文章看的我特手痒，想也写博客，但是问题就来了

博客的主题是什么？

我一直有着写点什么的习惯，以前总是休闲散文写的比较多，更多是偏向于一种日记类的文章。
自从看了陈皓和Jeff Atwood的技术类博客以后，总有种写好的技术博客的冲动。
因为我对逻辑、语言、思考都感兴趣，而我又不能准确描述我这些兴趣，那我就把它们都写出来好了。

XKCD的自我描述是

A webcomic of romance, sarcasm, math and language

希望我也能写出这种主题鲜明，又有趣又妙不可言的文章

我有什么能写出来的?

作为一个菜鸟，我最熟练的VIM水平其实放在网络上也只是一般
同时根据三人行必有我师焉，也意味着来到这个博客的人中每三个里就有一个比我厉害

（我是不是应该放一个博客访问计数器？然后每到三个倍数就alert(“Congratulations”)一下…

不过既然大家都比我懂的多，那我也就不怕献丑了。
好玩的，要费脑子的问题，或者对人生的杂念都会被我写下来。

中文博客还是英文博客？

讲道理的话，这个问题我想了很久。
以至于我都快走火入魔了，同样的文章写了一份中文的和一份英文的

后来想了想，主要基于几个观点：

母语是中文，所以中文写的会比英文写的更顺畅
语言的选择决定了受众的范围，而外国受众大部分不了解中国的亚文化
个人而言，以后认识的国内朋友可能会更多，这本身是一个不错的名片

于是，我便踏上了博客之路。

现阶段目标是每周一篇吧，就像Jeff说的一样：

Pick whatever schedule works for you. And be realistic. I think starting with one post a month, like Catto, is a fine goal. Try to slowly ramp it up a bit over time as you get into the groove, and you’re on your way.

我和女权的我打起来了

Thu, 27 Aug 2015 20:28:00 +0000

一直以来我都自以为是一个大男子主义的人，
但我和女权的我相处的都比较和谐。
但是今晚我和女权的我打起来了。

（一）

一直以来我都自以为是一个大男子主义的人，
但我和女权的我相处的都比较和谐。

但是今晚我和女权的我打起来了。

（二）

做完饭以后，我把每个菜都尝了一遍。

自我感觉还是挺不错的，只是菜的扮相不是特别好。

我忧伤的想道：
“假如我是个女的就好了，以后就找个有钱的，天天研究怎么做菜。”

这时，女权的我突然跳了出来：“你这样想是不对的！”

我在吓了一跳的同时意识到了我话里隐含的逻辑漏洞，
赶快心虚地解释道：“不不不，假如我是个男的我也找个有钱的…”

女权的我看出了我的心虚，一针见血地说道：“你潜意识并不这么想。”

男人嘴巴上的尊严让我让步不能，我于是反问：
“那就我找一个会做饭的，我去挣钱养家，可以伐？”

女权的我立刻就回答道：
“你不能这么想。只有女性在自己选择了想做饭以后，你才可以这么想。”

我眼神里充满了怀疑（别问我自己怎么知道的，真男人从来不照镜子）
“也就是说我是男的，依据女权的观点，我不能希望女的会做饭，但是假如我是女的，希望自己会做饭，这是可以的，而且是女权的？”

女权的我盯着我，想了一下：“对的。”

我退了一步，先使出一招<以退为进>：“所以其实女权是提倡平等？”

女权的我紧跟着，使出了一招<海阔天空>：“是的，女权其实就是平权，你微博读的不错。”

我立马使出连招<车五进一><猴子捞月>：“那所以根据平权的观点，我也可以希望自己的配偶是醉心于为我做饭的？”

没想到女权的我只用了一招<不动如山>就化解掉了我的所有言语：
“你个人可以这么想，但是有这个想法，你基本上就孤独终老了。”

（三）

可能是因为招数太华丽，有可能是因为无懈太可击，也可能是蚍蜉撼大树是两个好朋友，一走神我就发现自己出于了下风。

于是我放下了筷子，重新开始了游戏：
“假如说我是女的，而且我是男权的，我就希望老公棒棒的，我差差的，何如？”

“假如你是女的…”
女权的我一开口，我就松了一口气，还好女权的我没有反驳说“你不可能是个女的”。

在这个问题上我可真争不过，
毕竟我前几周才知道我一直爱慕的丝袜其实囊括了打底裤。

那一瞬间，我从“喜欢丝袜”的变态，变成了“喜欢打底裤”的傻逼。

不过话说回来，打底裤看起来其实也不错，关键还是要看腿。

“假如你是女的，你就不会这么想了。”女权的我简明扼要地告诉我。

这个问题我也争不过。
因为这个问题讲下去，就会变成“你又不是庄子，你又不知道惠子眼中的鱼知不知道自己是怎么想的”了，

而且最终还会变成“庄子//转发本条锦鲤”这样的东西。

我看了看渐渐变凉的饭和渐渐消失的饿，意识到我要先去收剩菜了
“我先去下厨房”

“哦”女权的我答应道。

（五）

“你咋去了这么久？”女权的我看我回来得比较迟

“没办法，一个人老做两人份的饭，收起来累，刚说到哪了。”我挺着肚子坐了下来。

“刚说到假如你这样的女生，肯定也是支持女权的。”

我有点不服气：“难道所有女的都是女权的？比如我有个儿子，那我也希望将来的媳妇要对他好给他做饭好好照顾他，这也不行？”

“的确，现实生活中有很多这样的婆婆，所以女权运动任重道远啊。”女权的我叹了口气，看起来很忧郁的样子。

我还是不服气：“就算按女权的观点，也不是万事平等的吧。扛东西肯定是男的来吧？万一打仗征兵呢？肯定是男的吧，可是会死人的。”

女权的我立刻指出了我题设的漏洞：“女权反对战争，不止女权，人权都反对战争。文明越发达，战争的可能性越少。”

想了想，女权的我估计是没有玩过《文明》的，就没有整下去了。

而且“可能性应该用小，而不是少”这句话也犹豫了一下，没有说出来。

看我有点踌躇的感觉，女权的我使出了终极武器：
“你刚才讲的的确是男性弱势的地方，但是那些发生机会都少，而女性，还要生育呢。”

听了这句话，虽然我心里有很多“不是说生小孩是自己选的吗？说好的选择了生育就选择了责任呢？”“说好的女性不是生育机器呢？”“男的也可以生小孩以后就不用女权了吗？”一系列问题，但最终还是没有说出口，点了点头表示了赞成。

因为突然想到了我妈，假如她也比较女权的话那她肯定活的比较自由，不用这么在意我了。

（六）

安静了一阵子，我问女权的我：
“其实我们讲话还是挺科学的啊，为啥我一直觉得我要和你打起来了？”

女权的我深了个呼吸，叹道：
“我也不想的。大概是整个社群比较激进，很多人的观点就是叫的越大声醒来的人才越多，我也不赞成这样的观点。但是没办法，毕竟辛德勒是在战乱结束以后才被拍成电影的，所以很多事情都要慢慢看的。”

我不禁赞同：“嗯，基督山伯爵也说嘛，等待，和希望。”

在气氛缓和了以后，男人残留在嘴巴上的尊严马上又让我跳了出来：
“不过我还是不赞同女权，我还是很大男子主义的。我觉得女性就应该柔弱一些，这样子不同性别的人都能发挥自己的特长到最好。其实女权和男权就应该像猪和驴在年货里的关系一样，反正我是不赞同男权的。说不定我还有处女情结呢！”

女权的我看了看我，笑道：“ツ没事，我也有处男情结。”

如何优雅地使用Perl的常量模块

Sat, 25 Jul 2015 20:56:06 +0000

最近的Perl Coding遇到了一个问题：需要对一系列常量进行合法性检测。

在Research&Develop后，有一些心得。

本文从Perl的常量定义上，给出一个_自认为_优雅的解决方案。

Perl中一般的常量定义

在写项目的时候为了避免Magic Number的情况，我们经常需要定义常量。

当然了，根据如何写出无法维护的代码的指导我们不应当定义常量，Number越Magic越好。

一般来说，Perl中的常量如下：

 use constant CONST_PI => 3.1416;

在模块化的编码过程中，随着常量的增多，我们会需要把这些常量放到一个常量模块(Perl Module)里面：

这样的做法也符合DRY(Don’t Repeat Yourself)的原则。#DRYBestPractice?

比如说在哼哧哼哧地写了一阵子以后，我们有下面这个常量模块。

 package Lirian::Constants;
 use strict;
 use warnings;

 #Math Const
 use constant CONST_PI => 3.1416;
 use constant CONST_E => 2.718;

 #Default Config Parm Name
 use constant PARM_DB_NAME => 'dbName';
 use constant PARM_DB_HOST => 'dbHost';
 use constant PARM_GIT_USER => 'gitUser';

 require Exporter;
 our @ISA = qw(Exporter);

 our @EXPORT_OK = qw(
 CONST_PI
 CONST_E
 PARM_DB_NAME
 PARM_DB_HOST
 PARM_GIT_USER
 );

 our %EXPORT_TAGS = (
 all => \@EXPORT_OK,
 math => [qw(
 CONST_PI
 CONST_E
 )],
 parm => [qw(
 PARM_DB_NAME
 PARM_DB_HOST
 PARM_GIT_USER
 )],
 );

上面这段代码简单粗暴地展示了Perl中的常量模块。

其中的our @ISA = qw(Exporter);是表示本模块继承了Exporter这个模块。

通过这样的定义，我们便有了一个常量的“中心仓库”了。

至于怎么使用，我们就来看下一节。

使用常量模块

在上一节中，通过对Exporter的继承，我们有了一个Lirian::Constants模块。

而一般地，我们会这么使用：

 package Lirian::Math;

 use Lirian::Constants qw(:all);
 use strict;
 use warnings;

 sub get_circum {
 my ($r) = @_;

 return 2 * CONST_PI * $r;
 }

 1;

在正常的情况下，常量的使用方法比较简单，但假如需求有些绕：

在程序的开始时，我们需要检验用户的配置文件，确保每个条目用户都是有效的。

比如说需求文件如下：

 dbName=github
dbHost=localhost
gitUser=LKI

显然地，一种简单但稍微蠢了点的方法是这么做：

 sub validate_config_dumb {
 my ($conf) = @_;

 validate_parm($conf, PARM_DB_NAME);
 validate_parm($conf, PARM_DB_HOST);
 validate_parm($conf, PARM_GIT_USER);
 }

这样做有几个问题：

1.config parameter一多，代码就很长，丑
2.增加config constant时，不仅要改常量模块，这里也要加，累
3.这样的代码提交上去感觉好丢脸，蠢
4.以上三点在撞大运编程里都不是问题

那怎么样做才算是优雅的做法呢？

利用Perl的Export机制

在Exporter中，定义在%EXPORT_TAGS中的文件可以直接引用：

 my $tags = \$Lirian::Constants::EXPORT_TAGS;
 my $math_tags = $tags->{math}; # ['CONST_PI', 'CONST_E'];
 my $parm_tags = $tags->{parm}; # ['PARM_DB_NAME', 'PARM_DB_HOST', 'PARM_GIT_USER'];

这样就可以拿到常量的名字了，此时我们便需要在Perl中根据变量名获取变量值

 my $name = 'CONST_PI';
 my $value = Lirian::Constants->$name; # 3.1416

所以在上一小节的问题中，我们可以得出一个更优雅的解决方案啦~

 sub validate_config {
 my ($conf) = @_;

 my $tags = \$Lirian::Constants::EXPORT_TAGS;
 my $parm_tags = $tags->{parm};
 foreach my $parm_name (@$parm_tags) {
 my $parm_value = Lirian::Constants->$parm_name;
 validate_parm($conf, $parm_value);
 }
 }

大功告成！从此以后在加常量的同时，validate_config会自动地检验新增的配置选项啦~

此时便可以使用一个酷炫的Git Commit Message来提交工作啦！

记一次有意义的吹B

Fri, 12 Jun 2015 22:06:00 +0000

（一）引言

我经历了一场绝妙的装B
可是这个地方太小写不下
——@ooCast

（可能内含各种广告）

（二）

某天下午和室友们吹了一场有意义的B，
当时觉得不记下来的话，毕设也写不安稳，
但是最后权衡了一下，还是毕设特么重要，
所以直到毕设写完了才开始记录这次寝室谈话。

记忆力和文笔都不好，请多担待。

（三）租房

话说最近在签三方的事情，和周丞一起去学生服务中心交表格。

路上我问周丞租房子的事情，
然后相互吐槽了一下租房还真蛮贵的，
想住的离公司比较近的话一个月就要2k~3k。

而且周丞懒，想租蘑菇公寓的房子，又要额外1k。

不禁感慨了一番在魔都干个十年，
要被房子吃掉好多钱，
而且在这里买房子真不值。

于是又探讨起了干十年就卷钱走人的可能性，
主要问题有2：

很可能三十岁回老家的时候还是单身
回去以后是否有对口的工作

周丞觉得第一的话现在相亲市场这么发达，不慌，
他认为到时候他就是有房、有车、单身、没有不良嗜好的优质大叔了

第二个问题倒挺忧伤的，
因为他查了一下，马兰坡Python程序员只有一个地方在招人：

芒果TV。

（四）毕业工作

后来回到了寝室，问小赖打算怎么样。

小赖说他出国没有理想的offer，想先gap一年，实习一下。

我和周丞便怂恿他找我们内推，小赖便问一天多少钱，
我们表示实习钱差不多，基本上都是180/d，转正后工资才是重要的。

小赖表示他不转正，这个不重要。

过了一会他又忍不住问“像我们这种码农值多少钱？”

于是我们展开了讨论，得出结论：

根据现状来看，第一年的基本上是100k/y到240k/y之间
正常的码农干个三年，几十万年薪是有的
再不济，随便学点C艹，Java，每个月拿半狗（150k/y)是有的
但是很少有码农能拿到百万年薪（周丞：知乎上就三个）

“走走走，看工作去” 我们三人凑在显示器前，默默打开了草榴…

唔…开错网了，于是我们关掉了草榴，

默默打开了赶集、智联、拉勾网、JobDeer和各种互联网公司的hr主页

（五）职业去向

到网上一搜，果然大部分都是招什么Java开发工程师，10k/m，要求三年工作经验。

然后我们又吐槽了一下，居然要求程序员工作经验，太扯了，
殊不知有些人是复制粘贴编译改Bug循环了三年。

我们觉得这个薪资太低了，果断按了高级搜索->筛选->月薪大于50k

然后出来的职位包夸：产品经理、美X网中国区总经理、总架构师blablabla。

面面相觑，
“难道我们干几年就几乎全部要转管理了？”

小赖表示他不服，他想当羽毛球教练（小赖：每次我去南体都觉得那个教练菜）

我和周丞极力赞扬他：“你看，羽毛球这运动很好的，很多白富美喜欢。说不定你就被看上了！”

于是我们就去网上搜了一下羽毛球教练的工资：6k一个月。

小赖表示他还是当程序员吧。

（六）钱的去向

乐观的我表示没事，虽然我们挣得不多，但是我们用的也少呀，
比如我们的社交费用会比别人少很多。

周丞：那不一定啊，我们会买游戏

小赖：游戏又没很多钱的

周丞：不不不，一个游戏虽然才几十刀，但是很多的还是很贵的

我：这个总比那些社交活动钱少吧…

周丞：而且我们那边的人天天去洗脚

我和小赖：啊？！？！？

周丞说他们那边的人去洗脚是一种娱乐活动，
要一两百一人次。。。

小赖表示这尼玛性价比太低了，还不如去大宝剑。

于是我们打开了大众点评，发现闵行的大宝剑才300一次。

我表示这个又不舒服又不安全，
还不如投资在以后的婚姻上呢。

（七）择偶观

我问“你们那边彩礼一般要多少钱？”

周丞“啊？还要彩礼，为啥？两个人平等的婚姻也要彩礼？”

小赖“我们那边都有彩礼的，毕竟嫁女儿嘛。”

周丞“那我妈还嫁儿子呢？凭啥我没彩礼…”

我“那你入赘就好了，入赘就不要彩礼”

周丞“啥是入赘。。。？”

小赖“就是对外宣称是你嫁过去了，然后你要住妹子家”

周丞“这么好？！？！好啊！没问题”

小赖“对，小孩还要跟妈妈姓”

我“啊，我就跟我妈姓的啊，入赘的评判标准就这些了吗？”

小赖“唔，好像就这些了…”

一阵沉默……（分析利弊中）

周丞表示其实不结婚也没啥，也就纯生物学意义上没完成传宗接代的功能，
假如真老了，还是没有老婆，那他就去捐精！

于是我们就到美国著名精子库fairfaxcryobank去围观了一发。

（八）饮食

正讲着，郁翔回来了。

由于他是魔都土著，我们就吐槽他在魔都有根据地，理论上有优势。

郁翔吐槽说其实他在左下角工作，家在右上角，一样也要租房。

说到租房，周丞又表示了忧郁：
以后饭怎么解决啊？

我们说现在饿了么这么发达，以后吃外卖就好了，
而且自己做饭未必比外卖便宜。

实在不行就请个小保姆嘛，说不定就发展出美好姻缘了。

但是请小保姆好贵啊！

郁翔表示这种东西跟程序员鼓励师一样不靠谱：
“假如有人在我写代码的时候在旁边说话，我肯定想抡死她”

的确，
面向对象编程的时候不需要其他对象了。

——记一次有意义的吹B

于 2015年06月12日晚10点

Vagrant-up遇到mount no device的解决方案

Fri, 15 May 2015 10:29:05 +0000

今天跑vagrant up的时候遇到了这个问题：

==> cvc-tools: Machine booted and ready!
==> cvc-tools: Checking for guest additions in VM...
==> cvc-tools: Configuring and enabling network interfaces...
==> cvc-tools: Mounting shared folders...
cvc-tools: /work => D:/work/
Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:
mount -t vboxsf -o uid=`id -u devel`,gid=`getent group devel | cut -d:
-f3` work /work
mount -t vboxsf -o uid=`id -u devel`,gid=`id -g devel` work /work
The error output from the last command was:
/sbin/mount.vboxsf: mounting failed with the error: No such device

查看了 https://github.com/mitchellh/vagrant/issues/1657
以后，明白这是yum update更新了内核，但是没有更新VirtualBox的连接的问题。

于是重新添加一下VBox：

[lirian@localhost ~]$ sudo /etc/init.d/vboxadd setup
Removing existing VirtualBox non-DKMS kernel modules [ OK ]
Building the VirtualBox Guest Additions kernel modules
The headers for the current running kernel were not found. If the
following
module compilation fails then this could be the reason.
The missing package can be probably installed with
yum install kernel-devel-2.6.18-404.el5
Building the main Guest Additions module [FAILED]
(Look at /var/log/vboxadd-install.log to find out what went wrong)
Doing non-kernel setup of the Guest Additions [ OK ]

根据以上信息，得知现在在跑的内核开发包缺失，于是再跑一下：

yum install kernel-devel-2.6.18-404.el5

之后再vagrant up或者手动mount就可以解决问题了。

总结：vagrant up遇到mount error: no such device可以通过以下脚本解决：

yum install kernel-devel-2.6.18-404.el5
/etc/init.d/vboxadd setup
mount -t vboxsf -o uid=`id -u devel`,gid=`id -g devel` work /work

与LL患者的对话

Tue, 10 Mar 2015 19:43:00 +0000

（一）

今天苍老师很开心地跑回了学校

他说他要去当一个热情洋溢的游戏策划

再也不用写代码了。

（二）

说到游戏，苍老师忧郁地说

“我入了LL的坑”

我立刻追问

“你有没有想草船借舰啊poi”

苍老师一脸荡笑

“LL的坑已经足够大了nico”

“哎，我已经肝了2K在国服了”

（三）

苍老师随即忧郁地说道

我同情地说

“没事，我玩秦时明月快一年也氪了1K”

苍老师悲情地看着我

“我1月入的坑”

“没事我也是去年5月才入的坑”

“我今年1月入的坑”

（四）

为了给我解释LL手游为什么魅力这么大

苍老师拿出了Iphone4

“日本人做游戏很精致的

就算是N卡也有她自己的剧情…”

苍老师盯着屏幕解说着

我看着苍老师

觉得有点理解为什么这么多人喜欢LL了

（五）

我又问苍老师

“LL这游戏花时间吗？”

苍老师想了下说道

“我中午肝一次

下午回家肝一次

晚上十一点半再肝一次

主要是我欲望比较强

现在除了国服还肝日服”

（六）

我又问苍老师

“那你还打算找妹子吗…?”

“找了妹子我就没时间陪老婆们了…”

苍老师回答道，我看着他

他也自豪地看着我

“我可是鸟厨！”

（完）

可能存在的婚姻恐惧

Sat, 28 Feb 2015 00:11:00 +0000

（一）

每时每刻都有一百万个想法出生，但只有一个人能把它记下来 —— 福楼拜

我不认识福楼拜 —— 高尔基

搞你的基吧！ —— 加菲猫

加菲好粗俗啊汪 —— 刚说完就被胖揍一顿的Odie

写题记可以，但是不要偏题太远 —— 语文老师

（二）

说到婚姻问题，时间大概是一年前

我爸和我进行了一场切磋

他先让我一招：

“儿子你有没有想过婚姻的问题啊?”

我立刻用浑厚的内力打了一招亢龙无悔出去：

“不以结婚为目标的恋爱都是耍流氓！”

当高中级长的我爸见招拆招，一记庐山升龙霸：

“那人在高中的时候能看得到这么远吗？”

我赶忙绕开，刷了一招海底捞月：

“我觉得只要两个人抱着真诚的心，那么结果是什么也是无所谓的”

我爸老谋深算，使用了我段数不足用不出来的四十不惑…

“我啊是见得多了，你这么小人生经验还不足……”

正当我在思考要不要用“我玩过的电脑比你看过的电视多”来反击的时候

我爸突然认真起来，使出了一招西方魔法里最厉害的除你武器：

“其实啊，我觉得西方那一套挺科学的。两个人互相有好感就在一起了，天长地久某一天，突然因为观念不和，哇，和平分手了，也没什么。于是这样很多场恋爱下来，最终能在一起的夫妻，肯定就是命中真子/女…”

我也是没想到一初恋就结婚甜蜜二十多年的我爸能说出这样的话

当场只好甘拜下风

（三）

从小到大睡在床上都不太敢看着天花板

假如一看就会觉得这个天花板为什么这么大啊

我的人是这么的渺小

因为实在是太弱小

所以有些事情永远不会跟自己妥协

我的人生也只有短短的一百多年

我没有时间筛选与选择

我只有时间等待与希望

在小的时候（真的很小）也不知道谁规定的

总是觉得以后说不定会单身一辈子呢

于是认真地了解了在中国要怎么样才能领养小孩

因为觉得不结婚是可行的，但是有两个问题还是很重要的

一是性需求，二是养育小孩的问题

毛主席说过自己动手丰衣足食，现在网络也发达

第一个问题倒不是很关键

想真正地养育小孩的愿望始终纠缠着我

但是可惜未婚男子最早也只能四十岁以后领养小孩

（四）

最近的语文水平大概已经退步到跟蚂蝗在一个级别上了

希望能准确表达自己的意思

世界上的智慧都在这两个词里：等待与希望 —— 基督山伯爵

一颗勇敢的心会自由地给予，自由地爱，直到受伤 —— 特雷莎修女

（完）

用Openpyxl做两个Excel文件的比对

Thu, 28 Aug 2014 10:31:08 +0000

起因

最近老是要做比对Excel报表的工作，于是想写一个Python的小脚本来做这个工作。
关于Python的Excel处理，以前只用过xlrd库，处理的是Office03的.xls文件。
这次写小工具的同时也是学习一下新的东西。

准备工作

由于本次要比对的报表是Office07的.xlsx文件，上网查了一下Python怎么做比较合适。
看了几篇心得以后，敲定用Openpyxl（参考如下链接：）

Python处理Excel的四个工具

于是接下来是装Openpyxl，到官网上按照流程装了一发：

A Python Library: Openpyxl

由于源码是到BitBucket上拖下来的，所以顺便还装了SourceTree。
据说SourceTree还有Git的相关功能，下次可以体验一下。

使用Openpyxl

Openpyxl装好以后直接import就能用啦：

from openpyxl import *

Openpyxl还提供了一个非常棒的教程~~（有点过于简单~~

Openpyxl Tutorial

Openpyxl还有个弊端就是文档不怎么详细，只能去翻源码。

最终代码

可以到我写的PythonScripts里找到我写的版本：

PythonScripts - ExcelComparer

我的好友陈伟杰

Sun, 20 Jul 2014 22:55:00 +0000

(1)

莫泊桑或者是福楼拜说过：
要写好描写性的文章，
你至少要写40个人。

综上所述，培根也说过：
知识就是力量，大家少吃培根。
我并不想写好描述性的文章。
我跟ED实在是太熟了，
不描写他一发简直心痒难耐。

(2)

ED，中文的名字是陈伟杰，
英文名字是ED。

跟别人介绍他的时候经常会是：

“这是ED。”
“诶！ED的意思难道是……？”
“不是的啦…只是名字简写…”

于是后来ED学会了一个新的词——蒟蒻。

(3)

我们口中的ED发音是'ed。

不过因为叫的多了，
所以“阿达”，“阿达娃”这种称呼也出来了。

有一次一个学弟对着他的名字念了个,i:di:'wəd

于是ED就又多了一个“一滴喔的”这样奇怪的外号。

(4)

ED在大部分网站上的账号都是edward_mj。

据他所说是因为edward这个名字实在是太常见了，
这样的账号都被抢注了。

于是他只好加个mj的后缀，
意思是“马甲”。

久而久之mj反而成了他的本体……

现在浙大的同学都叫他“马甲”……

(5)

ED并不介意熟人怎么叫他。

事实上对熟人在大部分事情上ED都相当随意。

某次我们annually跑到ED家附近去玩，
大家怂恿ED来BG一发，
ED就很鱼块地BG了一发。
最近ED用自己的服务器搭了个能上Google的业务，
他也直接拿出来给大家用了。

(6)

但是ED在生人面前看起来非常地羞涩&正经。

由于混熟了以后大家对于ED感觉反差太大了，
于是ED获得了很多好友的一致评价：“（闷）骚”。

至今还有很多人叫ED“骚杰”

ED觉得非常蛋疼，
问我：“你说为什么会这样子捏”

我想了想，
说：
“可能是因为你真的很（闷）骚吧。”

其实骚也没什么，
屈原也骚。

(7)

初中的时候我在1班，
ED在2班，
本来理论上不会太熟，
但是我们在信息竞赛（OI）班里是同桌。

初中的OI其实就是大浪淘沙，
由于很多假期都要留校，
实在是太寂寞了，
于是很多对此没多大兴趣的人都弃坑了。

所以初一还有五、六十人参加的竞赛班，
到了初二就只剩我、ED、Li、LuLu、何升雨和孙艳梅了。

人比较少，
我们每个人就有了自己固定的座位，
我就跟ED成了同桌。

从初二到高三，
一直同桌了五年。

(8)

后来跟冯可聊天的时候，
她还很惊奇地跟我说：
“你也跟陈伟杰同桌呀。”

冯可是ED小学时候的同桌，
她觉得“ED实在是太受了，
谁都能欺负他“

这句话说的太对了。

ED高一的时候坐在大灰和烨哥的中间，
那阵子他们两最大的爱好就是戳ED。

ED又怕痒，
每次被戳都会像保卫萝卜里的萝卜一样抖动……

于是大灰和烨哥就更喜欢戳ED了。

(9)

认识ED以后跟他聊天，
他说了一件初一的时候特别好玩的事情。

当时我的一班和ED的二班，
语文老师是同一个人，
大学刚毕业的热血青年。

有次晚上寝室卧谈，
ED他们寝室玩打电话的恶作剧游戏。

有个同学就播了语文老师的电话：
“您好，
这里是红袖午夜情感电台。
情感故事请按1，
美眉聊天请按2……”

然后（开着外放），
电话对面沉默了许久，
传来了一声“嘟”的按键声……

他们一寝室强忍着笑，
问：

“请问你按的是1还是2啊？……”

……

(10)

假期的时候在寝室的只有学奥赛的几个同学，
于是我、ED还有Bill三个人就睡在同一个寝室。

当时ED有个翻盖的手机，
这手机侧面有个非常酷炫的功能键，
按一下就能兹兹地自动翻盖。

我和Bill都非常喜欢玩这个按钮，
于是没有两天这个键就被我们玩坏了……
不灵了……

我们三个人都感到了蛋疼……

(11)

ED很多时候会灵光一闪地表现出无以匹敌的2B气质…

有次假期留校，
早上起来我们在阳台刷牙。

ED刷着刷着，
突然感慨了一句：
“其实，我觉得我大腿还是比较粗壮的！”

我愣了一下，
然后笑疯了……

哈哈哈哈哈哈哈至今想起来还是想笑…
太逗B了……

(12)

其实ED很瘦，看起来跟竹竿似的。

而且ED比平均身高都高
（就是在班里坐最后一排的水平

几年前有次坐在我爸车上，
在跟我爸随便聊天，
我爸突然说：
“最近不是流行一个词‘高富帅’么，
很多人都被称为‘高富帅’，
我看啊，
陈伟杰才算是‘高富帅’…”

不得不说我顿时膜拜起了我爸的博学，
和我刚学会的侧面描写……

(13)

ED家住在市中心，
我们有一个玩的非常好的朋友圈，
所以基本上每个假期我都会跑到他家住几天，
跟他在市里疯玩一圈。

ED爸妈在生活上对ED非常好，
就算是晚饭我们在外面吃完回来，
晚上在房间里聊天上网，
他麻麻也会端碗切好的水果给他。

ED家还养了只狗，
ED说这只狗智商很高。

不过我看到的都是一只2B doge：

地板拖得太干净太滑，
这狗爪子也干净，
所以只要一见到人，
它就会很开心地滑倒在地板上……

(14)

到了大学ED参加了ACM
(Association for Computing Machinery-International Collegiate Programming Contest)
（简单的来说就是世界大学生信息竞赛）

大二大三带领着浙大从中国打到俄罗斯总决赛，
打了两届Final。

做个比喻，
就像是2018世界杯，
ED带领浙大足球队冲出中国走向俄罗斯……
（这个比喻太奇怪了啦

问ED在俄罗斯比赛之外有什么感想，
ED说：

美眉太多了！
俄罗斯的人为什么不学英语！
国外的WIFI真难上！

(15)

长时间的逻辑训练让ED思路异常清晰。

所以ED可以在任何情况下清楚地知道自己想要什么，
不想要什么。

所以ED了解自己以后应该怎么发展，
哪些人可以帮到自己，
怎么做可以解决问题。

所以ED没有女朋友……

(16)

这点ED也非常忧伤：

ED：我这个人也不差，
为什么没有女朋友呢？
我：可能你太2B了…
ED：我也是很有威♂严的！…
我：那可能你太羞涩了…
ED：熟了以后我什么都敢做！…
我只能说：那你蛋疼…！
ED：……
ED：好吧…我蛋疼……

(17)

俗话说物以类聚，
ED跟我在很多频率上非常一致。

这次ED来上海，
他神秘兮兮地问我：
“B站上那个
《老夫从来没见过这么漂亮的妹子》视频你看过没？”

我：“哈？那是啥视频啊…”

于是ED翻出来给我看，
我听了两秒钟：
“这不是马来西亚的四叶草么！”
（https://www.acfun.cn/v/ac1195212）

简直一拍即合。

(18)

ED最近把微信头像改成了钢炼里的EDWARD，
ED说他们不仅名字一样，
都有弟弟，
而且这个动画也挺好看的。

ED以前的头像是阿狸，
他特别喜欢这只胖狐狸。

于是那阵子他壁纸、表情、头像全是阿狸。

后来ED喜欢散华礼弥。

于是他把个人主页的封面图都改成了散华礼弥。
（https://edward-mj.com）

理工男喜欢一个东西就是这么一根筋。

(19)

三年前，ED去浙大之前我跟他说：

“你到时候找到女朋友了一定跟我说，
我假期一定让你带她回来，
我肯定不会跑到你房里去玩了 ;-)”

三年以后，ED非常忧虑地跟我说：

“我觉得某种意义上浙大和交大是一样的…”

我安慰ED：

“没事的。你看你们学长2009，
他不也没有女朋友么，
他比你更悲剧呢。”

顺带科普了一发2009与九阴真经的梗给ED……

(20)

中学的时候我就想，
ED应该就是我最好的朋友了。

于是我和ED从来没有说过“多联系”这样的话。

任何时候，
只要有什么好玩的事情，
郁闷的事情，
我都直接一句：

“ED”

戳开了聊天窗口。

这就是我的好友，
陈伟杰。

0x5f3759df 一个神奇的数字

Fri, 07 Mar 2014 14:11:31 +0000

今天在看各种算法介绍的时候看到了这么一句话“神奇数字0x5f3759df并不是约翰·卡马克发明的。之所以一开始被误解，主要是许多对卡神光环膜拜已久的游戏程序员在读Quake3源码时吓尿了……”一下子引起了我的好奇心，在查阅了一些资料以后整理整个故事如下。

雷神之锤3

雷神之锤3（Quake3）是90年代的经典FPS游戏，不仅画面精美，而且整个程序优化得很好，在配置一般的电脑上也能流畅地运行。这主要归功于其3D引擎id Tech3，而此引擎是由约翰·卡马克（John Carmack）领导开发的。

卡马克是一个美国码农，id Software的创始人之一，他因在3D技术上的杰出成就而文明。卡马克还是一个开源软件的倡导者，1996年他放出了雷神之锤的源代码，而一个程序员将其改写成了Linux的版本并发给了卡马克。卡马克没有认为这是侵权，反而是要求他的员工们以这个补丁为基础开发雷神之锤的Linux版本。后来的日子id Software也一样公布了雷神之锤2的源代码，在2005年，雷神之锤3的源代码也被放出来了。

（这是官方下载地址ftp://ftp.idsoftware.com/idstuff/source/quake3-1.32b-source.zip）

我们知道，越底层的函数调用越频繁，假如把底层函数优化做好了，效率自然就上去了，3D引擎归根到底还是数学运算。在最底层的运算函数中（game/code/q_math.c中），有许多有趣的函数，有些更是令人惊叹这究竟是如何编写的。

神奇的0x5f3759df

在运算函数文件中可以找到这么一个函数，它的作用是将一个数开方并取倒数，功能上跟系统函数(float)(1.0/sqrt(x))一样，但是效率上快了四倍：

float Q_rsqrt( float number )
{
long i;
float x2, y;
const float threehalfs = 1.5F;
x2 = number * 0.5F;
y = number;
i = * ( long * ) &y; // evil floating point bit level hacking
i = 0x5f3759df - ( i >> 1 ); // WHAT THE FUCK?
y = * ( float * ) &i;
y = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
// y = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed
#ifndef Q3_VM
#ifdef __linux__
assert( !isnan(y) ); // bk010122 - FPE?
#endif
#endif
return y;
}

这个函数最核心，最令人费解的就是标注了“WHAT THE FUCK”的那一句

i = 0x5f3759df - ( i >> 1 );

再加上一句y = y * ( threehalfs - ( x2 * y * y ) );就完成了求开方的运算。

一般的求开方采用的都是牛顿迭代法，比如求sqrt(5)，那么先令A = 2然后B = 5 / A; A = (A + B) / 2;这样循环下去，A和B将会越来越接近，最终的结果就是根号五了。而卡马克给出的这个算法的牛逼之处在于它直接用了0x5f3759df一个数猜测了一个值，通过一次计算就很接近根号N的值了。这样省下了许多次迭代逼近的过程，那么函数效率则也就大大被优化了。

普渡大学的数学家Chris Lomont了解到了这个数字以后很感兴趣，他打算研究一下这个数字的奥秘。这个Lomont也是一个牛人，精心研究以后他从理论上推导出了一个最佳猜测值：0x5f37642f，跟程序中的0x5f3759df十分接近。Lomont得出这个结果以后很满意，他拿自己这个数跟卡马克的神奇数字做速度比赛，结果卡马克赢了……谁也不知道卡马克是怎么求出这个数的……

自己精心推导出的理论最佳值居然输给了卡马克，Lomont也是很不甘心，他用类似穷举的方法一个个地试过来，终于被他找到一个比卡马克的0x5f3759df要好一丁点的数字：0x5f375a86。于是Lomont很高兴地把这个结果写成了论文公之于世……（论文地址：https://www.matrix67.com/data/InvSqrt.pdf）

这个算法也有了自己的名字：平方根倒数速算算法（Fast Inverse Square Root）

算法的发明者

因为约翰·卡马克是整个雷神之锤项目的开发者，所以起初很多人也就简单的认为神奇数字0x5f3759df是卡马克的杰作。但是后来卡马克本人在回复问询邮件的时候否定了这个观点，卡马克回忆可能是雷神之锤项目的一个资深码农Terje Mathisen写下了这段代码。而Mathisen回复邮件则表示他以前的确写过类似的代码，但他并不是先行者。现在了解到最早的实现是Gary Tarilli在SGI Indigo中实现的，但他也表示他只是对常数进行了一些改进，实际上他也不是作者。

虽然并没有定论表示整个算法究竟是谁发明的，但是大家还是津津乐道于卡马克、和他的神奇数字0x5f3759df。

参考资料：
https://www.guokr.com/post/90718/
https://www.matrix67.com/data/InvSqrt.pdf
https://www.matrix67.com/blog/archives/362
https://en.wikipedia.org/wiki/Fast_inverse_square_root
https://en.wikipedia.org/wiki/John_Carmack
https://zh.wikipedia.org/wiki/%E5%B9%B3%E6%96%B9%E6%A0%B9%E5%80%92%E6%95%B0%E9%80%9F%E7%AE%97%E6%B3%95

妈的，交大

Fri, 11 Jan 2013 19:57:00 +0000

（一）

前几天，浴室

又听到旁边的基友众在讨论游戏

大学男生嘛，自然就“他妈的关羽居然没杀”

“宙斯出什么JBBKB啊”

再前几天，旧行政楼户籍科

安静的窗口前只有大四学长在咨询关于转户口的事情

这让只是来询问身份证掉了怎么办的我有点恍惚

终究有一天我们也会来户籍科的。

（二）

我爸说，来交大的人大部分都憋着一口气

他们差那么一点就能去北京。

我只知道很多人一开始并不喜欢交大

甚至会讨厌交大晚上断网

不过正如小王子所说的

让沙漠变得美丽的，是他在不知道什么地方藏好的一片绿洲。

交大的很多细节渐渐地让新生们迷恋上了

二餐卖炒饭的阿姨最后总会送点什么东西给你

你甚至可以直接从HL外卖哥那里买外卖

交大的猫特别亲女生

某月某日桂花就像计划好的一样突然都冒出来了。

骂着“妈的浴室真TM远”然后哼哧哼哧地抱个盆子和室友去洗澡

说着“妈的高数真TM烦”然后因为老师一句真性情的话大笑起来

想着“妈的无论是谁都好请和我交往吧”然后觉得在交大单身其实也没什么

反正以后都“要嫁就嫁交大男”的嘛，虚什么。

（三）

有两句话以前很流行，

一句是“在网路上，没人知道你是一条狗”

另外一句是“家乡就是那个你已经说了一千句不是但是你不允许别人说一句不是的地方”

第一句话和本文没太大关系，只是用来说明以前是有多以前而已。

交大的一天除了学术、生活、还有数千句的“妈的”“卧槽”。

但是就是这个让你每天说妈的的学校，在你离开之后

就会变成你的Mother School。

数年后，说着“妈的想当初五月份的时候交大里都是石楠花的味道”

但是说妈的的心情已经变成了想Mother的心情

（四）

只有呼吸困难的人才明白他在呼吸

在我还没有沦落到一谈当年满腹回忆的时候

我还是要说声，妈的，交大

（完）

想写一个小故事，姑且写之

Fri, 15 Jun 2012 12:52:30 +0800

很久很久以前，在一家糖果店里，有一个很美丽的米色糖果。

她还小的时候不懂事，她爸妈都很爱她，她的糖衣最甜最美，她蹦蹦跳跳地独自走向橱窗。

她遇见了红色糖果绿色糖果还有一颗黑色糖果。

红色糖果说你不应该是米色你的糖衣应该是更好看的颜色。

绿色糖果说你的米色很好看啊我喜欢然后靠近米色糖果偷偷地把自己的颜色蹭上去。

黑色糖果说你的米色很好看你应该做你自己。

红色糖果有很多绿色糖果有很多黑色糖果只有一个。

米色糖果不知道听谁的，而且这种事情只能自己做决定。

米色糖果决定遗忘自己的颜色和大家都当好朋友。

这个故事没有结尾因为作者已经找不到米色糖果了。

只有黑色糖果很悲伤。

昨天与朋友关于弹幕网站的聊天与感想

Wed, 16 May 2012 12:48:16 +0800

　　言语不清请各位谅解。正文从第八段开始。

BGM请戳这里：AC娘的重生

昨天晚上九点多网管部的同学BG①，于是没吃晚饭提前洗了澡去吃烧烤。大概有二十多人到场，然后例行的吃东西聊天玩游戏②。

聊天聊着聊着一个同事MM③就在起哄要我唱歌④，机油们也跟着起哄。

众人起哄中HJ⑤问起为什么要叫我唱歌，她得到这样的回答：“浮云⑥唱歌很好听的呢！”“都发到网上去了！”“很多弹幕哦！”

HJ显得很激动：“你发到哪个弹幕网站上呀？”

我还没有回答，旁人已经帮我回答了：“ACFUN！”

HJ便一脸“我懂了”的表情，看着我笑道：“AVFUN啊~”

我也笑着问她：“你上AC么？”

HJ（笑）⑦：“我是混B站的。”

我：“恩，B站也是很好的弹幕网站哦。”

此后又聊了一圈别的话题，然后穿插着我唱了几首歌⑧，玩了一阵子游戏，又聊到了弹幕网站的话题。

HJ（跟之前提到的同事MM说）：“回去把视频地址发我。”

同事MM：“他的视频弹幕可是有很多的！”

我（弱）：“没有啦，这个有上限的…”

HJ（高兴）：“浮云我跟你说，我很喜欢B站的原因是因为这个弹幕太好玩了！”

我：“是呀！”

HJ（认真且自豪）：“我最近在B站上看冰与火之歌，那个剧透看的好爽！什么‘前方高能反映’的。”

我：“……⑨”

我（嘀咕）：“又黑我大小学生！”
机油（暗暗窃笑）：“哈哈……”

HJ（继续说）：“而且弹幕很多时候会有神吐槽的！”

我（赞同）：“对对对，这个有。”

HJ（举例状）：“比如‘这不科学’啦，‘打开的方式不对’啦……”

我（囧）：“这些比较流于大众化啦，神吐槽其实指那些对很有特色的剧情而特别的吐槽……”

HJ（听我说完以后）：“其实是‘打开的方式不对’还是‘打开的姿势不对’呢？”

我（科学地）：“两个都可以。”

HJ（说着说着捂嘴笑）：“当时我们为了这个争论很久，然后争着争着就把喵叔⑩打开了…”

然后又是一阵没有边界欢乐的聊天。

HJ：“诶，B站的叫‘up主’，A站的叫什么？”

我①①：“A站的也叫up主啦。”

HJ（好奇）：“其实A站和B站是什么关系呢？”

我（想了下）：“这么说吧，弹幕网站最开始是日本的niconico。ACFUN可以说是大陆的首家有影响力的弹幕网站，后来鸟大了总会有林子的，于是ACFUN的环境有一段时间不是很好。于是有一个原来在ACFUN的动漫爱好者叫九碧时去创立了一家网站，就是现在的bilibili啦。”

HJ（发问式的言语）：“我觉得A站很多喷子…”

我：“怎么说呢，唔……宽泛的来讲，B站的动漫氛围要比A站好，A站的话，有很多ZZ，JS论坛的同学会来逛。B站对言论管制的比较厉害，发不太和谐的评论和弹幕很容易被封，A站相对比较宽松，所以整天可以看到喷子出没啦。其实我觉得喷子还是挺萌的，比如说弹幕网站上的这两种人：一种是我这样的，看到喜欢的内容会哈哈哈哈的笑，这时候我大部分时间都不会发弹幕‘我太喜欢这一段了’；而喷子们一般都把手放到键盘上，一看到自己不喜欢的内容就幽怨地发一句：‘这段好烂哦’‘我不喜欢这段’‘这种也发上来？’。其实理解了他们还是觉得他们好萌的！”①②

这段后话题又转向了别的地方而且没有转回来了。

以下为个人感想可以跳过，分割线后为注释。

我们不能认为自己就是正确，世界/时辰/AC就是错误的。我希望AC永远是小众网站，但是我也希望我的朋友能理解AC，爱AC娘。AC里，有人只去文章区，也有动漫宅，也有我这种鬼畜音MAD爱好者，还有音乐爱好者以及更多没被提到的人。AC娘每天都要接待各种各样的人哦！

我内心是认为网络应该是向二次元世界一样美好的。个人而言，我从来不会把什么负面激动的情绪暴露在很多人眼中①③。我想说给别人的、影响别人的都是我觉得是很正面的情绪，比如“开心”，“笑话”，“愉快”，“温暖”。虽然我也很赞同那些阐述黑暗事实而宣扬自己心中的真理的人，但是我始终认为每个人的世界观要被言论改变是一定要有事实支撑的，我们如此红脸争执①④，为何不如一笑而欣赏生活中那些美？

我喜欢AC娘，喜欢她越来越美，越来越好看！

最后，祝你们身体健康，再见！

①BG，论坛用语，主要意为“请客吃饭”。

②从我少得可怜的经验来说，聚会玩的游戏以惩罚游戏为主，什么猜数字啦，接龙之类的，基本上都是输了然后羞耻play什么的…当然昨天也学到了一个名叫“几匹马”的游戏…

③MM，论坛用语，释为“妹妹”or“美眉”，已经是脱离时代的叫法了。现代叫法应该叫“妹子”，不过个人不喜欢这个称呼。

④杀破狼什么的，被机油发现然后发到了群里去了。于是三次元有一些人知道以后，称“哇原来还以为你是一个挺安静内敛的人……”

⑤HJ，网管部的前辈学姐，人称虹姐，为了便于记事以下称HJ。

⑥浮云即楼主，此处真名替换，以下不释。

⑦本人不能完全再现当时场面，括号中为表情为今天的回忆，一群人吃饭气氛还是很欢乐的，所以大部分时候都是笑着，下文就不给特写了。

⑧在别人面前还是不敢用狗耳模式唱歌，只能好好唱。

⑨当时其实心里很认真的在思考HJ这是开玩笑的呢还是开玩笑的呢，不过HJ认真的表情以及后来的话语、行为都表示她说的其实是实话。

⑩喵叔，网管部同事，属于有知识且温顺的那种人。

①①其实HJ应该是那种天真可爱的弹幕网站受众，说不定他们就是弹幕网站流量的最大贡献者。

①②当时这段话好几个地方好像HJ都有话说…但是我实在是忍不住于是一口气说完了，没给HJ插嘴的机会。现在回忆起来这么做应该不太对。

①③当然也有和二次元好友聊天倾诉苦逼生活的情况……

①④此处想到一个笑话：
有一天动物们在关公庙前面闻到很臭的味道。
蛇说：「我这么小不会放这么臭的屁，一定是牛。」
牛说：「我是吃草的不会放这么臭的屁。」
猪说：「放屁的人一定会脸红。」忽然关公冲了出来，把猪打飞说：「说了多少次了，我脸红是天生的。」

（完）

杰克之死

Thu, 27 May 2010 12:00:00 +0800

“杰克死了。”

“真的？不可思议！”

“太可惜了，我一向看好他的。”

“活该。”

“死了他一个，还有后来人。”

“杰克是谁？”

“一个人总是这样，死了比活着更出名。”

“听说奥巴马表达了哀思。”

“可以放假吗？”

“别管他，反正迟早要死的。”

“前几天我还见过他呢。”

“这可以拍成电影…”

“我终于可以放心地出去逛街了。”

“怎么现在到处都在讨论他？”

“杰克已然成为了一种现象。”

“我是他高中老师，我有话说…”

“请问他…他…”

“他乐于助人，挺好的…”

“浮躁的风气始终困扰着中国。”

“杰克死的好。”

“她死了就死了，值得讨论吗？”

“我觉得他不应该死…”

“我反对，他应该死。”

“Jack?Who do you mean?”

“《泰晤士报》报道…”

“这是一场精心准备的操作。”

“昨晚他给我托梦了。”

“其实他脚踏两条船被发现了。”

“他的死是个迷。”

“对比悲哀的杰克，讨论的人们更悲哀。”

“捷克是成千上万死人中平凡而又特殊的一个。”

“我活着…”

“最近有人打着杰克的旗号行骗…”

“他曾经喜欢过我，我觉得，他不配。”

“只有聪明人才能看到杰克现象的本质。”

“杰克不是现象…”

关于我

Mon, 01 Jan 0001 00:00:00 +0000

朋友，你好呀。

我叫苏子岳，出生在湖南岳阳。
这个名字的由来也跟我的出生地有关：
父母既希望我像诸子百家一样才华横溢，
也希望我像山岳一样坚实可靠。

Lirian Su 是我的英文名。
Lirian 是我高中写的小说的主角之一，
他的人设就像我期望的那样：
文可静心作解，武能以一敌百。

我出生在湖南，在广东求学长大。
初一开始参加信息学竞赛接触编程，
后来高中参加 NOIP 得的省一等奖，
让我可以免高考保送到上海交通大学，读软件工程。

2014 年 7 月大四以后，
我在 QAD China 实习工作，
QAD 是一个跨国团队，
我也在这学到了教科书般的软件开发流程。
当时主语言是 Perl，
做的是基于 Git 的定制化代码版本控制工具。
后来在我逐渐成长为主程后，
推进了整个项目的一次大重构，让项目的性能跟复杂度都得到了优化。

2016 年 10 月的时候，
我被百姓网HR邀请去面试，
因为好友周丞以前实习工作也在百姓，于是就约了一顿饭。
结果被他以一碗重庆小面拉到了现在的公司。
现在的公司简称叫再惠，
刚来的时候整个公司的技术只有12个人，每个人都很强，
我感觉自己是里面最菜的 :)
我把我的工作体验在知乎上面写了下来，
当时我并不知道这篇文章会在后面几年安利了不少人加入再惠。

工作上我一开始做的是 Web 后端的活，
主要工作包括了大后端会涉及的三个部分：
实现业务逻辑、设计管理数据库、搭建服务器部署环境。
这里每一块都有很多东西可以讲，
所以我就不讲了 :)

2018 年 1 月开始，
我作为一条业务线的技术负责人开始带着团队向前冲，
不少人直接跟我说过：
“你是我最喜欢的 Leader.”
这样的话也勉励着我，
不仅要让努力的同事获得事业上的奖赏，
还会想尽办法让大家一起走在技术的最前线。

在担任 Team Leader 的几年来，
我每周都跟团队的伙伴们有着固定的周会，
大家一起分享技术、讨论职业成长。
我真心开心的一点，
是跟我一起工作的伙伴们离职率都比较低，
这也勉励着我继续向着更好的方向去努力。

2022 年 2 月开始，
我加入了北极数据。
主要负责上海研发的我，
也兼顾了产品的职责。
在北极的一年多，
我在更深的水里体验到了数据、AI、技术行业创业的感受。

创业是一个被说烂了的词语，
本质其实就是人与商业。
对于人来说，思考、拼搏、信任都是关键的要素；
对于商业而言，现金流、模式、创新则至关重要。

2023 年 9 月，
我受再惠创始人赵洋的撩拨，
又开启了在 OpusClip 的旅途。
这段旅途是我最近几年来最享受的过程，
有机会再好好给大家讲讲。

从一线开发成长为技术负责人以后，
我也一直把自己当一个主程序员在用。

工程上，我会推动项目去遵循社区的最佳实践，
因为这样才能最好地利用各种工具来偷懒增加生产力。
语言上，我主要写 Python,
对 Go/JavaScript/Perl/Java/Lisp 有点了解（排名分先后）。
Life is short, I use Python.

我还主要在知乎、GitHub 上保持活跃。
我在知乎主要当个看客，
但 GitHub 里我会参与不少项目。
我自己的项目主要分为两部分：
一部分是我自己的生活项目，比如我的个人主页或者是我的环境配置；
另一部分是各种工具项目，比如判定节假日的库就挺受欢迎的。

我习惯的开发环境是Windows，
是一个重度的Vim用户和Git用户，
也是JetBrains大礼包的受害者。

喜欢语言和逻辑，
喜欢好玩的事情，
喜欢读博客，
~~问题很多~~好奇心很旺盛。

很喜欢Python Zen里的一句
Now is better than never。
认为生命的意义在于现在，想做什么就不应该犹豫。

相比于覆盖100%情况的复杂设计，
更喜欢覆盖90%情况的简单设计。
我相信大道会是简单而纯粹的
（比如说我坚信存在大一统理论）

相信人生而平等，
也相信一部分人会活得更加平等。
但不管怎么样，生活是由自己创造的。

希望老了以后回顾自己的生命，
能坦然地念出这句诗：
苟利国家生死以，
岂因祸福避趋之。

不喜欢贴标签，认为每个人最重要的是独立自由的身份。

不喜欢后悔，不喜欢争执，认为事实说明一切。

不喜欢政治，因为我觉得政治是不透明且不会公平地。

不会主动参加社交活动，
平常空余时间基本在陪女朋友。
当然了，现在女朋友已经是我夫人了，
她在持续更新一档名为不可逃课 BookTalk的博客节目。

我的梦想是世界和平，好人都能幸福，
以及要成为一个很厉害的人。

很高兴认识你。
（不过假如你读完了我的自我介绍，
不跟我介绍一下你的话，
我就没机会认识你了。）

关于本博客

搭建博客很简单，做个决定却不容易
由Hugo生成, 挂在GitHub上,
评论系统是用的commentit，PV和UV是用的busuanzi

附录

最近我花在写代码上的时间：
(没错，这个哥最近写代码的时间变少了)

最近我用的编辑器：
(我查数据的 GUI 也是 PyCharm)