包含标签 技术人生 的文章

为了打个广告,coding pages 变得好邪恶

Coding Pages 是我的博客承载平台。我的博客是用 Hexo 做的,Markdown 语法书写,编译成静态 html 后上传到 Coding Pages 和 Github Pages 上面去,供大家访问。之所以用两个不同的 Pages 服务,是因为之前 Github 被 GFW 墙了,包括 Pages 在内的服务都访问不顺畅,彼时正好 gitcafe pages(后来被 Coding 收购)也提供 Pages 服务,所以在国内做了个镜像。这样墙里面的网友不仅不用看 GFW 的心情,还因为服务器在国内,国内网友访问时更快一些。谷歌上一搜『hexo github coding』就能有很多结果,例如这篇『将hexo博客同时托管到github和coding』。 但是好像从上个月(八月)开始,coding pages 开始劫持我的博客访问,穿插进他们自己的企业版 coding 的广告,播放五秒之后,再跳转进入我的博客。这很优酷、很爱奇艺,很 APP。广告页面上甚至连一个倒计时的控件都看不到,就右上角(好像是)一行很小的字,跟你讲:*你没访问错,这个页面只是广告*。 看了 coding 的解释,你要不花钱买它的会员(金牌会员),就要在你的博客页脚上加『hosted by coding pages』的字样。如下图。 大家注意截屏上方的绿色警示框:这是我的 pages 通过审核之后的状态。下面标红的复选框需要你在添加脚标之后自行选中,之后就会有专人给你审核开通免广告插入。 我猜测这是 coding 为了给自己网站做 SEO 的小伎俩。考虑到用了 coding 免费服务有一年多两年,人家要求也不过分,虽然网上很多人吵着要离开 coding 转 github,我还是决定给人加一个脚标。做人要懂感恩嘛。 这之后,痛快了几天。 真的只有几天。 然后,coding pages 抽风了。表现症状是,我输入域名访问我的博客,它不显示我的博客,甚至不显示广告,义无反顾跳转到他们家企业版的首页。我的博客看不了了。如下图。 不知道 coding 家到底有多想要做 SEO、做 PR。人家 OSChina 比你们家的 PR 还低,人家也没想 SEO 想到这个份儿上。……

阅读全文

从程序猿到架构狮的转变

从程序员到架构师的成长,变化就像从小学生到高中生一样巨大。 不仅是对能力有要求,更重要是对视野的要求,对认知能力的要求,对沟通能力的要求,对组织能力的要求,对适应能力的要求,对执行力和韧性的要求…… 远不是说技术能力成长了,就达到了架构师的要求。更加不是说技术能力有了,*培养培养*,就可以成为架构师了。架构师都是摔打出来的。 看到过对*做架构*有一个不错的定义:系统架构的目标是解决利益相关者的关注点。 所以你看,做架构的架构师,其实是解决人的利益问题,目标是让各方利益尽可能达成一致,做 trade off 的工作,权衡。技术只是实现这个目标的一种手段,一种重要的手段,手段之一,不是全部,甚至于不是最重要的。执行层面成长起来的、技术能力过关的工程师,想要成长为架构师,首先考验的是你听 + 说的能力,也就是沟通表达的能力。沟通能力才是一个合格的架构师最重要的能力。 一、听的能力 这个很有学问。 我们常常假设与我们沟通的都是理性人,他们清楚自己说的是什么意思,他们也确实想要表达这个意思。实际上,几乎不存在这样的理性人。为了避免尴尬、隐藏真实想法,大家说的往往是加以润色的话。即便死党之间畅无不言,潜意识也会偷偷在话里打掩护,顾左右而言他。若是拿别人告诉你的话当个准,九成九会遇到『当初我怎么知道』的情况。 工作中也是如此,系统架构牵扯利益,各方都希望架构师做出有利于己方的设计,所以表达己方利益关切的时候,明明可以『关注』的,他可能用『严重关切』来表达。你没法儿指责他说谎,也许他的表达习惯就是如此,也许是大家对轻重缓急的表达方式不同。但作为架构师,你自己心里就得有个判断:他的话我到底该不该信?信几分?可信的部分在我的架构中轻重缓急怎么判断? 所以,听的能力非常重要。 首先,学会听别人的话外音。 职场上,大部分人是理性的,他们对自己手头的事情能有理性的判断。大多数时候,他们也能清楚知道自己想要什么。只是,他们往往会*委婉*地表达自己的目的。旁推侧击、敲山震虎、隔山打牛、杀鸡儆猴…… 就是不会直来直去。 作为架构师,你得学会听懂别人背后表达的意思,这是最基本的功力了。 其次,听懂别人背后的意图。 再聪明的人也有犯糊涂的时候。有些时候,跟你沟通的某人,会忽然卡壳,不知道接下来要怎么表达/表达什么。他隐约觉得自己想要个小功能,但就是不知道怎么表达出来。这时候如果架构师对这个人有一定了解,知道他关心的点,知道他的风格,就有可能顺着他的思路去提醒他。 倒不是让架构师去做别人肚子里面的蛔虫。这样做至少有两点好处。 架构师主动提,比一个有明确利益偏向的人来提,提出来的方案合适得多。他讲不清楚的时候,你能讲清楚,还照顾到他的关切,他接受你的方案的概率也很高; 如果架构师对利益方能达到这种程度的了解,可以把利益方的偏好尽可能纳入架构设计的考量中去,就可以做好预埋,防止无谓的需求变更。 最后,听懂别人没说出口的话。 有些话,不一定要说出口,就像上面提到的。另外有些话,说的时候还没想到,或者,说的时候就没怎么想,反正可以以后想到再说。 对架构师,后面两种情况真的够呛。你遇到的是一个*职场 baby*,一个不能为自己的行为负完全责任的人。这种情况下,最好的解决办法是,你能帮他想好,反过来引导他,通过他的嘴讲出来。避免在系统评审会之后,频繁变更带来的成本开销。评审会之后变更架构设计的开销是客观的,成本存在压缩极限;而考虑提前量的开销是可控的,通过人为努力可以使成本逼近零。因此在系统架构设计阶段,尽可能多考虑一些未来的变化,从长远来看,是相当划算的。 这种场景下,考验的是架构师的业务能力、经验和宽泛的倾听技巧。这种能力通过练习可以培养,但成长不会很快。属于二八原理中要花 80% 精力去积累的 20% 那部分。锻炼的时候,要有耐心和信心。 说的能力 说,或者说表达,也是沟通中重要的一部分。对于架构师而言,架构设计就是最好的表达。相对的,就工程师成长起来的架构师,我更提倡学会倾听,而不是表达。 如果硬要说在表达方面有什么建议或者窍门,就下面几句话。 先听别人说完,自己再说; 说之前,想清楚,尽量言简意赅。话说得太多,在别人耳朵里,就没什么效果了。不如一字千钧有威力; 想表达不同意见的时候,先停顿三秒,再说出口; 有理不在声高; 对事不对人,对过人的自己请客吃饭; 培养能力 沟通的能力也是可以靠锻炼来的,不是谁生下来就是《九品芝麻官》里面的包大人。关于沟通的锻炼方法,极限一点的,请自行谷歌销售技巧培训方法。哈哈 最后补充一句,沟通 + 技术能力,是成为一个架构师的必要条件,还不是充分条件。这两条具备了,才可以说你达到了做架构师的最最基本的要求,有可能做出大家满意的架构设计。后面的,有机会再补充。……

阅读全文

数字公司旗下的 SSL 服务商好像被 block 完了

刚知道,Apple 早在去年就开始 block Wosign 和 StartCom 作为根签发的 SSL 证书。 继 Symantec 被 google 亲儿子 chrome 拉黑之后,感觉信息安全圈儿的很多事情忽然变了,有『忽如一夜春风来』的感觉。以前是知道有这么些事儿,藏着掖着谁都不说明白,资深的自己玩儿,小弟捡漏,群众连瓜在哪儿都不一定知道。现在是感觉被子掀开,太阳晒进来,虫子晒死一堆——还有大虫子,而侥幸活着的挪个地儿,继续往阴暗处爬。照这趋势,被子迟早彻底掀开,那会儿会怎么样,真不知道。就我知道,glibc 的 hostname resolve 漏洞和 openssl 心脏滴血都是开胃菜。想对隐藏的『大 boss』有直观感觉,请看斯诺登泄密的那些文件。 开源可持续的其中一个前提是:大多数贡献者积极向善。就像最近很火的区块链,确保账本正确、资金安全的前提是,不诚实节点掌握不了超过全网 50% 的运算力。否则,保存在全网区块链中的账本,被人篡改的几率就大大增加,账本不可信,资金不安全,你账户里面躺着的钱有一天会突然变成 TA 的。随着这些年技术门槛降低,互联网开始普及,互联网经济不再神秘,趋金的商人也越来越多走进来,捞钱。他们在互联网经济中所占的比例会越来越大,最后他们的影响力一定会超过作为『互联网原住民』的工程师。趋金不是个贬义词,由它引发的故事却往往是贬义的。这些故事,最终可能会毁了开源,或者说『进化』开源。 阳光下的 M$ 这么多金,届时 M$ 会不会趁虚而入要了这只企鹅的命,还真不好说。 看开点,随个缘咯。 selinux 也是可怜的孩子,生不逢时。网上的小白教程讨论的都是『怎么关闭 selinux』,知乎上也只有『为什么要关闭 selinux』这一类的问题。 在技术发展水平不变的前提下,安全和方便是一体的两面,要想安全,一定会比较麻烦;想不麻烦,就会不安全。可以选择权衡,本质不会变。没有环境倒逼,恐怕很多企业都不会对安全太上心,这就是现状。安全是非功能需求,往往也是次要需求,安全对应的麻烦则被视为成本,追求『绝对安全』的动力不足,只要相对安全就好。而且,这种『相对』的标准,往往还是领导/客户心理上的相对,跟事实差好远。……

阅读全文

用户就是个数字(外两则)

这两天有种忙得不亦乐乎的感觉,倦怠了写博客。 用户就是个数字 要说的是关于鹅厂邮箱的事儿。标题是很多大公司做产品的哲学,当然也包括鹅厂自己家的。 我是鹅厂毕业,也算是鹅厂粉丝,但凡能鹅厂产品能满足要求的地方,就不会用别家的产品。企业邮箱就是一个例子。 我的个人常用邮箱以自己的域名作为后缀,最初放在腾讯邮箱的『企业邮箱免费版』上,用了有两年左右的时间,一直很正常。一直到这周朋友给我发送邮件,被退回来,提示邮箱不存在一类的错误。我才注意到,原来我的免费版的企业邮箱被腾讯单方面终止了服务,正在使用中的邮箱无法收发邮件,甚至无法登陆,从管理后台登陆上去才了解到是域名无故被解绑。而在这之前,无论是我绑定了该企业邮箱的微信,还是企业邮箱本身,被抑或企业邮箱的管理账号,都没有收到任何相关的提示信息。 我首先排除管理账号被盗、黑客为之的可能性。很简单,腾讯企业邮箱的那个管理账号我很长很长时间没有使用过,账号名是一个我从来没有在别的地方使用过的字符串,不存在被社工被钓鱼的可能性。而且管理后台中,我的企业邮箱绑定过三个域名,除开今年有一个因为域名到期没续费自动失效当即被清理,一个我一直在使用中的域名无故清除,只剩下一个绑定后几乎没有使用过的域名。如果是黑客捣鬼,为什么单独给我留一个没使用过的域名?这讲不通。 后来有朋友在朋友圈中留言,了解到原来有朋友也遇到过,也是腾讯企业邮箱免费版,绑定的域名下有一个用来做客服的邮箱,经常在登录使用,也是毫无预警的情况下被清理,并且也是从后台直接解除了整个域名的绑定。 不同的是,朋友用的邮箱在两个月前失效,我的邮箱是在一个月前失效。分批分次在清理免费邮箱——而且是不给你任何预警、提示、通告、宽限期、选择项…… 直接让你的邮箱和邮件消失掉的清理。 到现在,这事儿几乎很明显是腾讯邮箱人为在清理的动作。因为太没底线了。按照腾讯一贯的价值观,这绝对不是一个『正直』的事情,这样的服务态度也不完全不符合『水和电』的特征,更加不『值得尊敬』。 在大厂做过 2C 产品的同学都知道,用户不过是一个庞大的数字,和员工自身利益休息相关的 KPI 也是通过评价这些数字,来调节对员工的奖惩。对于每一个单一的用户,大厂的产品真的是多你一个不多少你一个不少。 今天正好看到广研大 boss 张小龙在微信事业群管理大会上的一个演讲,明确要求内部不要盲从流程和 KPI,要坚持用户价值导向。真的说得很好。他还特别举了 QQ 邮箱的例子,这是个大家都比较熟悉的例子。当年 QQ 邮箱从上不了邮箱服务 Top10 排名到后来逆袭压倒 Hotmail 和网易邮箱,方法是小团对敏捷开发,背后的思想仍然是坚持用户价值导向。如果企业邮箱的团队能够坚持用户价值导向,是一定不会做这么出格的事情。 希望老东家能越来越好。千万守住自己的底线。 139 邮箱之乱象 又是邮箱的故事。 我的 139 邮箱在 2014 年设置过一个别名,这样可以用英文名而不是手机号作为邮箱前缀,识别度更高。我拿 139 邮箱主要是在国企那段时间用来收发工作上的邮件。 然而自开通邮箱别名开始,就经常收到一些莫名其妙的邮件,邮件经常开头有名有姓,称谓是我没听过的名字。刚开始以为是骚扰邮件,没有管,后面类似的邮件来得越来越多,我也听之任之,反正这个邮箱后来几乎就没有怎么用过了。 这周忽然收到一封邮件,是微博发送的,提醒我登录别名邮箱对应的微博账号。很奇怪,我不可能用 139 邮箱注册微博账号。担心邮箱帐密被盗用作什么不好的事情,于是通过微博的找回密码服务找回了账号对应的密码(后来知道,微博账号如果没有绑定手机,那么别人拿到你的邮箱,随便使用一个手机也能找回密码),发现是一个运营了三四年的企业微博,企业地址在上海。到此我才恍然大悟。 在我设置 139 邮箱别名的时候,我设置的这个别名其实是有人在使用的。不知为何,139 邮箱仍然把这个别名分配给我。所以我经常收到本该属于另一个用户的邮件,而且猜想那个用户同时也能收到本该属于我的邮件吧。一个别名邮箱,我们俩都有在使用,不论谁发送邮件,我们俩都能收到。 最后我给我们俩『共用』的别名邮箱发了消息,告诉他这个情况,并承诺把微博密码还给他。希望他能看到。 邮箱作为互联网基础服务,服务的稳定性应该要有最基本的保障,安全和隐私也应该要能做到最基础的保障。这跟邮局里面申请一个邮箱一样的。可是一周内竟然遇到两次大乌龙,我也是醉了。 所幸我还有一个 gmail 注册的企业邮箱。从今天起,免不了后续会逐步把常用邮箱换成那个。 在天朝,用个邮箱都能吓死宝宝。 关于运维的笑话 有个运维跟中学同学聚餐,接了个电话,大家都吓尿了。。。。 『喂,是我。』 『怎么回事?……卡在哪儿了?』 『不行就杀了吧,做事别磨磨唧唧的。先保证业务正常。』 『啥?找不到?杀不了?你不知道 killall 啊!把这个名字的全干了。』 『嗯。』 『诶?怎么还报警了!』 『你让胡总赶紧把警报先关了。你就在现场,报警有个屁用。』 『你跟他好好说一下,就说是我说的。这破事儿二十分钟内就能搞定,不要动不动就报警。』 『嗯。』 『对,挂了也要拉起来,就没什么不行的!他敢挂掉你就再拉一个。』 『擦!早不挂晚不挂,这会儿挂,真特么不是时候!』 『行了,我马上过来。都特么不给老子清净!擦!』 ………… (o_o) 『我不吃了,要去加个班。喂,你们都看着我干嘛…… 』……

阅读全文

『东航两飞机险相撞』事件中的飞行知识

今天无意中打开 Maxthon,看到了推荐的一则旧闻——『东航两飞机险相撞』。我记得事件当天就有看到这则报道,当时的第一反应是:类似荷兰皇家航空发生的空难(特内里费空难)在虹桥机场被避免了。今天看到的更多是后续报道,新闻报道的焦点几乎都在 V5 的机长和疏忽的管制员身上。 俗话说,对航空航天没点儿兴趣的码农不是好的 CTO。凭借我多年积累的航空知识,和对航空事业发展的关注——其实就是对各城市机场航班老是延误的那点儿感性认知——跑道入侵征候(被规避了,不算空难)在今天不能算是罕见。不过这次这个事件号称是相差三秒相撞,事后也被定型为 A 类跑道入侵事件,说明事件本身还是非常严重的。 下面摘自澎湃新闻的后续报道。 通报称,这是一起塔台管制员遗忘飞机动态,违反工作标准而造成的人为原因严重事故征候。性质极为严重,属于A类跑道入侵,险些发生飞机相撞。当时两架飞机垂直距离仅19米,翼尖距13米,两机仅差约三秒就会发生碰撞。320机组果断处理,操纵正确,避免了一起事故。330机组接受了穿越跑道的错误指令后,虽然看到了飞机起飞,但并未提出质疑。 通报认为,管制员违反相关规定,盲目指挥,双岗制责任落实不到位;专业人员资质是重中之重,自制能力要跟上;管理手段和工作流程存在问题,要系统思考原因,加以改进。 通报还提到,330机组存在SOP的问题,观察不周,不按规定,关闭了应答机。带飞左副驾驶不知道东航穿越跑道程序。没有交叉检查,没有互相证实。但是机组没有机械听从塔台原地等待命令,加速穿越,避免了两机相撞,暴露了训练上的问题。320机组处理非常到位,临危决断,立了大功。副驾驶操纵迟疑,点了一下刹车,机长迅速接过操纵,以7.03度/秒的速率,带杆到机械止动位。 首先明确了这是一起人为因素造成的事故,而且是塔台管制员疏忽占主因、A330 机组占次因的事故。事后调查表明,A330 机组存在 SOP 问题,以及观察不周、关闭应答机等问题。 其次,报道中提到了 A320 机组在事件中临机处置立了大功。7.03度/秒的速率,带杆到机械止动位,才避免了两机相撞的事故。当然,这其中还有一个明显的对比:『副驾驶操作迟疑,点了一下刹车』,后来『机长迅速接过操纵』,才避免了机毁人亡的悲剧。 这其中有多个航空相关的知识,自己也是边看新闻边搜索,记下来,也给其他有兴趣的朋友科普一下。 基础概念 跑道入侵 具体的知识见维基百科跑道入侵条目。 按照定义,很显然,本次事件中,A330 错误地出现在飞机起飞和降落的保护区域表面,是一起跑道入侵事件无疑。 据悉,通报指出,此次事件性质极为严重,属于A类跑道入侵。 据业内人士介绍,“A类跑道入侵”非常罕见。目前,民航界把跑道入侵分为以下五个级: A类,间隔减小以至于双方必须采取极度措施,勉强避免碰撞发生的跑道入侵; B类,间隔缩小至存在显著的碰撞可能,只有在关键时刻采取纠正或避让措施才能避免碰撞发生的跑道入侵; C类,有充足的时间和(或)距离采取措施避免碰撞发生的跑道入侵; D类,符合跑道入侵的定义但不会立即产生安全后果的跑道入侵; E类,信息不足无法做出结论,或证据矛盾无法进行评估的情况。 按照《民用航空器事故征候》标准,A类属于航空器严重事故征候,B类属于一般事故征候。据悉,根据新下发的文件,“A类跑道入侵”是指必须立即采取极端措施才能避免相撞的跑道入侵。 ——摘自传送门 新民晚报 客机离地起飞的介绍 这里有一篇通俗易懂的科普文《客机驾驶探秘Airline Pilot 3.3 起飞离地》。 为简化阅读和防链接失效,同时把重点摘录整理如下。 PFD PFD,直译过来就是『主飞行显示屏』,主要用来显示飞机的飞行状况,以及计算机给出的一部分飞行建议。 上图是波音 737 的 PFD。其中,紫色的倒 V 字型标识是 FD 指令条(Flight Director Command Bar),下面白色的倒 V 字型标识代表自己的飞机。按照例子中的状态解读:飞机需要执行拉起 +8 度抬头的操作。 上图是空中客车的 PFD。Flight Path Director (FPD) 线是计算机所给出的指令,Flight Path Vector (FPV) 表明飞机处于的方位,飞行员要控制飞机使 FPV 处于 FPD 的中心。此例中飞机左转时机头向下,应保持左转并拉起 +4 度抬头。……

阅读全文

从技术管理 title 看公司的技术解题思路

互联网技术线的职业发展轨迹到今天已经很清晰,大体来说两个选择,要么继续深入走技术专家路线,当个架构师、研发专家,向计算机科学家方向迈进,要么转管理路线,从小组长做起,向 CTO 迈进。 这是正向的。反向,从一家公司技术负责人的 title,也能看出这家公司在技术方面的解题思路及现状。 1、招聘组长 / leader / 主管的,注意留意这家公司最近招聘攻城狮的岗位 JD。 通常直接在 JD 里面说招聘 leader 一类 title 的非大厂企业,通常的意思是:我们需要一名高级攻城狮。至于你能不能胜任 leader,需要在工作中观察。不过不管怎么说,能把 leader 提出来单独招聘,是有意识在补充团队的中坚力量,应该给个赞。 这一类企业,留意他们最近招聘攻城狮的 JD,一个是 JD 中的任职要求,是否有侧重点,是否描述清晰,大致可以看出这个团队遇到了什么问题。第二是看看攻城狮 JD 中的薪资范围,可以从侧面了解这家公司攻城狮的待遇水平,也可以看出公司对这个角儿的期望,是个管培生,骨干,还是个救火队长。 2、招技术总监的,企业是希望用管理手段来修补技术问题。 技术总监的职责偏管理而非技术,这是大家都有共识的。公司少一个技术总监,言下之意就是公司觉得技术管理上出了点问题,需要个人来补救。再换个角度翻译就是:希望通过技术管理来提(ya)高(zha)技术团队工作效率。 走技术总监这条线,等于就是走技术管理路线了。而且,一定是管理工作大于技术工作。 3、招架构师 / 首席架构师 / 研发专家的,通常是需要一个救火队长,少数是准备做大~~~项目。 架构师 / 首席架构师 / 研发专家这几个 title 是在技术线的,现实中很多企业里面已经是到技术线顶端了。 需要这类角色的企业,不少是需要一个能带队、独当一面的技术骨干,有不少企业在招聘的当下还面临一堆代码腐烂的系统,和一个问题重重的团队。能应聘这个职位的,跟应聘技术总监类似,入职后都要面临非常大的挑战,不同的是管理层的期望。能放出这个 title 的空缺,企业管理层是期望用技术的手段来解决现阶段面临的问题。 4、招 CTO 的,要么是一穷二白的创业小作坊,要么是高管层对产品的把控已经一筹莫展。 首先明确,CTO 在一家职能完备的企业里面,是高管角色,背的业务指标的,关心的是产品技术团队为公司业务增长提供多大的助力,对一个产品能不能实现、实现得好不好,他不负直接责任只负管理责任。同时,也意味着 CTO 对公司的主要业务必须非常熟悉。 创业小作坊招 CTO,基本上都是期望用 title 吸引住人才;而稍大一点的企业招 CTO,释放出来的信号是,高管层希望有人能通过对产品工作全权负责,来保增长促发展。 不管怎么说,就像 Fenng 自身遭遇的事情一样,CTO 这个角儿不好做。 另外还有一种常见的技术高管 title,叫『技术 VP』。这个基本上是活儿照干,但是不享受最后胜利果实的意思。企业招这个角儿的意思通常是:需要这么一个背业务指标的技术高管,你很合适,但又觉得你对企业带来的收益不高,比如没有一个好履历不方便放出去拉融资,所以把 CTO 的位置空缺,等遇到更合适的人,随时把你一脚踢开。 如果不是公司大到一定份儿上,招这个角儿的公司都是在耍流氓。 作为一名技术出身、想要升阶的求职者,首先搞清楚自己的期望,然后选择合适的职位去求职。不管最终选择什么样的岗位,都需要做好一件事:管理好别人的期望。而一个连自己的期望都管理不好的人,肯定没有办法管理好别人的期望。……

阅读全文

日常随记

今年 今年还真是一个特别的年份。夏季刚来不久,天还没到最热的时候,老丈人就过世了。等入了伏,我们听了一整个夏天的救护车呜呜声。吃饭的时候,『呜呜呜呜呜』;在街上散步的时候,『呜呜呜呜呜』;坐公交车上,『呜呜呜呜呜』…… 有一次在家吃饭,救护车从楼下过了四次。重庆婆婆家楼上有老俩口和小儿子同住,结果做保安的小儿子下班回家,发现老俩口热死在家里——他们家竟然没有装空调。还有最近心脏猝死的山东大学生们。没有熬过今年的人,好像特别多。 另外,今年的蝉也特别多,多到建行放 ATM 的小门面里,小小不足十个平方,一到晚上,容纳了不下十只蝉,到处飞肆意闹。早晨出门,街边随处可见死掉的蝉,有些还趴在汽车前挡玻璃上,裸露在晨光里。鬼知道今年哪儿来这么多蝉。 自己动手 Homebrew 是 MacOS 下不错的工具,一个包管理器,码农最爱。不过人家一直没出稳定版,最新的好像才 0.9.9。最近就遇到一个不爽的事情:php56-grpc 这个包安装不上,编译阶段报错。仔细一看,原来用的扩展版本是 0.5.1 beta,人家扩展已经到了 1.0.0 stable,难怪。 于是干脆,自己修改 formular 升级,并提交了 PR。爽。中间顺带还解决了 ext-grpc 的一个 bug。 同时也深深感觉谷子哥家的东西,还真不是一般人能够触碰的。你要用,你就得懂。各种依赖,甚至于对他家私有库的依赖路径,都大大咧咧放进来。一旦遇到报错,要是没耐心跟还真不知道该怎么弄。幸运的是,这次人家就犯了一个小错误,改起来特别简单,顺手改完提交一下。 开放平台 蚂蚁金服成了互金行业名副其实的霸主,前段时间机构找个人投资者接盘蚂蚁金服股权的爆料显然并没有阻止它的快速成长。参照阿里系其它业务的发展轨迹,料想蚂蚁金服最近两三年会有个非常漂亮的成长曲线。 昨天才发现,蚂蚁金服在这个月(八月十日)发布了开放平台。 互金的开放平台还真不多见。印象中支付宝的开放平台做了一段时间之后,很快也就不能完全『开放』,半遮半掩地走着,运营上也完全没有再推。微信的开放体系中,与互金有关、涉及到支付的部分一直就没稳定过,从我亲身经历的项目来看,貌似财付通的技术限制让人捉急,不过也从来没看到微信从运营上推这部分的业务,反而是申请相关权限的时候接受审核力度很大。其它家,像什么京东、百度、腾讯开平…… 几乎都很少放开与金融相关的功能。特别是创业以来,我自己接触互金行业之后,感受到如果真放开的话,这其中的问题非常多,实际操作的时候平台侧会承担相当大的风险。因此,看到蚂蚁金服(支付宝)在如今开放平台遍地开花的时候再次推出自己家的开放平台,怎么说呢,一方面吃瓜看个热闹,另外一方面还真想看看他们会怎么去做这个事情。搞不好,金融行业真能因此进入『互联网+』的时代。 这是个不断触碰监管者 G 点来做创新的行业。希望蚂蚁金服能在除了『流量营销』和『会员管理』之外拿出更多有意思的玩儿法。……

阅读全文

互联网创业怎么做产品技术规划(一)

从鹅厂出来之后的这几年,在创业公司做了很多产品技术方面的实践工作,得到一些关于产品技术管理方面的心得,这部分比实际完成一些什么样的系统设计和开发更加宝贵,这是有钱都买不来的。后面一段时间,我尽量将这些心得以博客文章的形式写出来。 之前尝试过大而全和分章节的描述手法,在废弃了十版左右的草稿之后,决定还是用随笔的手法吧,划定一个小范围,想到哪儿写到哪儿,不拘一格。大而全格局太大,自己荒废了很长时间没写文章,把控不住;章节形式专业性太强,没做好写论文的准备,就不拿一些带主观心得的东西贻笑大方了。 相较于我刚开始学互联网编程的那段时间,也就是二十一世纪初的那几年,现在的互联网盈利模式更加清晰,业务和产品趋于红海竞争,值得去尝试的蓝海领域越来越少。带来的一个好处是:产品技术方面能够复用的东西越来越多。 举个现实中的例子。因为花椒、映客等等关系,最近遇到一些朋友想要做直播平台,要我给他们建议。我大致估了一下,质量上以产品原型计,大约有百分之八十以上的组件,包括比较难的 P2P、DHT、CDN、视频实时压缩等都有成熟的第三方解决方案,只有涉及到所谓『痛点』的大约百分之十几的那部分逻辑需要自己去做。这些成熟的第三方解决方案不管是开源软件也好,还是云服务的方式也罢,都能避免创业者重复造轮子,大幅降低开发维护成本,还能提高用户体验。 然而更厉害,就算是差异化的那百分之十几的逻辑,我们现在也可以利用工程化的手段让它们的产出更加高效更加顺畅。 最近一年我在创业公司积极推进一件事情,就是把初级工程师的成果有效化。出发点是帮助公司降低对工程师水平的依赖,用技术手段提高工程师的工作效率,提高输出成果的有效性。这事儿说透了也很好理解:既然创业公司的项目需求更多是原型实现,并且还有那么多可靠的第三方资源可用,技术团队也就更像是在做集成,而不是技术创新,对工程师的初始能力要求不应该特别高。当然,公司肯定也会同意,因为省钱嘛。o(╯□╰)o 创业公司对初级工程师倒不一定有什么特别的偏好,不过创业公司的 boss 们大多对技术人才无法做到『准确识人』,这是事实。有时候哪怕他们自己想找一些大牛合作,也苦于无法辨别。就算找到真正的牛人,在工作方式方法上通常也会出问题,至少是让其能量发挥不出来。所以干脆的,很多创业公司 boss 与其花冤枉钱碰运气找大牛,不如直接找初级工程师先实现原型好了。很无奈,也是事实。既然是事实,我们首先得尊重它,而不是抱怨,然后才能往后考虑,怎么样改进。 当然,先解释下:依靠初级工程师实现的原型在技术上是不是能够拥有可扩展性,今后是不是可以生长和健壮起来,是个问题。考虑到这是架构师在开工之前需要完成的设计工作来决定的,不可能指望初级工程师去完成,所以这点不在我们今天的讨论范围之内。所以首先,假设我们有一位有能力有担当并且对项目理解深刻的架构师吧。 话说初级工程师的工作一般都不可靠,特别在他们工作拥有自由度的时候,自由度越高则可靠性越差。要提高初级工程师的工作有效性,首先考虑的是怎么『约束』他们,降低他们可以自由发挥的空间。这个思路跟现在流行的互联网『颠覆』的观点可能会有点相冲——你把空间限定死了再做事,还谈什么互联网颠覆呢。不过我认为,就现实中的中小公司创业环境,技术上的创新总是局部的,否则研发成本太高,就是作死,运营和产品上的创新才是具有颠覆性的关键。 通常我给初级工程师『画地为牢』限定他们工作空间的办法有下面几种。 必须全程参与需求评审,独立完成功能设计文档。会议和文档化是让很多工程师头痛的两件事情,但是在任何团队中,首先要保证的大家目标一致,花点精力在统一目标上,经验告诉我们,绝对值。 统一的代码风格和注释要求。每种语言都有好多种代码书写风格,团队统一采用一种就好,这没什么可争辩。至于注释,最好也要统一一下要求,以便工程师可以在代码中合理添加注释。代码风格可以通过 lint 来检验,而注释则只能通过代码审核的过程,人工指正。 代码审核后才能合并到开发分支。一方面是代码的质量控制,确保代码仓库里面的代码都是有效代码;另外一方面,代码审核恐怕是帮助这些初级工程师成长最快的方式。一个好的 reviewer 胜过任何职业培训学校里面的任何授课老师。 一个严厉的非黑即白的框架。我不会浪费时间跟初级工程师在技术方案的可行性上做探讨——你当然这样做也能实现功能那样做也能实现功能,但你就是得按照我说的做。整个团队都是这样。没得商量。而保证这一点的最佳手段,就是用一个非常严厉、越雷池半步就报错的框架。 统一的开发环境和部署环境。同样,我也不会在这方面跟工程师们有太多商量的余地,必须统一。部署环境由于涉及到运维的配合,与用框架不同一样,从一开始就必须大家都统一。不同的是,开发环境这方面我通常会给工程师们一个过渡期,过渡期内我会推荐我认为效率最高的系统、IDE 甚至 IDE 配置文件,并且提供支持。通常来说,一到三个月的过渡期之内,就能把这事儿统一下来。 保持一致的沟通腔调。技术上,各种专有名词和特定的描述方式很多,沟通中大量使用专有名词虽然有时候看起来很装逼,但这样的确可以大大提高沟通效率。对初级工程师,以及我们的产品经理同学,通过在文档、会议中不断加以引导的方式,来强化他们对一些常用名词和描述方式的概念,让他们既能懂也能用,从而提高整个团队的沟通效率。 这样执行之后,做执行的工程师基本上不再可能有什么自助发挥的余地,就像谷歌技术团队的风格:一千人写的代码,读起来就好像是一个人写的。无论是代码和注释的书写风格,功能实现的方式,都是一致的。这样的代码就算放个两三年换个人来维护,也没有障碍。 另外一方面,想要提高工程师效率通常意味着激发个人的积极性,释放他们的工作热情,同时帮助他们扫清工作之外的障碍。从字面上理解,这和上面限定他们的空间相左。说细了,不矛盾。 统一的开发环境、沟通腔调,降低沟通中的障碍。在拥抱变化的场景下,沟通随时随地都在发生,如果不能把沟通过程做顺畅,尽力消除沟通中的阻碍,工作效率自然没法儿提高。初级工程师最容易遇到的问题就是遇到问题表达不清晰,想帮助他也无从下手。统一开发环境、沟通腔调,团队成员基于一个场景在沟通,效率自然就提高了。 把开发流程中重复的步骤工具化。例如:分情况 pull 代码;根据事件和关键词创建新分支;检测代码风格;部署代码到线上之前跑单元测试;部署代码到线上服务器;排查应用日志…… 如果每次手动做这些事情,势必影响编码的连贯性,把它们做成工具,每次运行一两条命令就可以完成一件事情,不仅可以提升工作效率,还可以提高试错的次数,小步快跑、敏捷迭代。 研发生命周期的管理从头到尾要做好,对工程师尽量友好。工程师只有一个工作是有效的,就是编码,其余的工作都是辅助,不能直接产出价值。所以,工程师越能专注地编码,生产效率越高。除需求评审和写文档之外的必要开销,确保工程师大部分工作能够在两到三个界面完成,是最优的结果。这就需要团队能有一套很好的研发管理系统,不是松散的几个第三方工具,而是一个有机的整体,涵盖整个研发生命周期。听起来很高大上,可喜的是,对创业公司也有第三方的选择,只不过需要自己做集成。 生产环境要有带检索的日志系统和调试工具。这个就不说了,也可以看做是从第二点中延伸出来的。单独提是因为,线上排错不知道坑了多少工程师的时间,熬夜加班,专门等午夜人少时重现错误,说多了都是泪。浪费的时间不是一点半点。 能帮工程师把编码之外的工作梳理清楚,减少他们被干扰的次数和时长,对于提高生产效率,规避编码中的 bug 效果很好。虽然上面几点在创业公司里面实施起来有些难度,但做总好过不做。况且,其中一部分已经有第三方成熟的解决方案,具体实施的时候只需要做集成即可。 在是给与工程师一个明确的施为空间,帮他们扫清编码障碍之后,技术团队在执行阶段的高效率,维护阶段的清爽,都是可以预料到的。这些准备工作虽然表面看不到有什么明显收益,但是对于公司在中期对外连续作战帮助非常之大。 附录一:推荐的几个第三方工具和服务 代码仓库:gitlab。同时基于 gitlab 的 web service hook,还可以扩展出涵盖大半段研发生命周期的系统,以此完成工具化的搭建。 需求管理:tower。这个纯粹是个人习惯,其实 worktile、trello、teambition 等等都不错。tower 虽然也有 api,可以做信息流集成,但貌似只限于收费的 Pro 版。 OS + IDE:Linux + vim。作为后端码农,这是不二选择。在这个前端要会用 linux 的时代,不会 linux 不能作为理由,只能是工程师自己的耻辱。前端码农根据项目不同,酌情选择更优的 IDE,例如 xcode(iOS APP)、atom(React)、Android Studio(Android APP)等。 后端开发框架:Laravel(PHP)。作为一款大量应用现代语言特性的开发框架,laravel 的缺点也是它的优点:太多的新特性,让初级工程师困在它规划好的地盘里,只能照做。 ……

阅读全文