Category Archives: 科技评论

用移动数据预测特斯拉产能

  之前介绍过Bloomberg通过网上抓取VIN(车辆识别码)估算Tesla Model 3的每周产量(今天的公众号也会转发)。最近又看到Thasos的另一种手段。

  Thasos Group分析了特斯拉厂房范围内的手机信号,显示通宵轮班在6月到10月之间增加了30%,他们与对冲基金客户分享了数据。特斯拉7月宣布 Model 3产量几乎翻了一番,这一消息使得该公司股价上涨9.1%,而Thasos的客户则能提前预测这一结果。

  8月份,特斯拉在美国市场的销量超过了奔驰、宝马和奥迪。北京这里特斯拉也开始满街跑。这特别像诺基亚被iPhone干掉之前的情形。不管短期内有多少问题,长期看特斯拉一定会更好,这是本质决定的。

  看了一下官方网站,Thasos拥有一个高品质的手机位置数据库,可以做很多事。例如为梅西百货(Macy’s)、诺德斯特龙(Nordstrom)、Dillard’s(狄乐百货)和西尔斯百货(Sears)进行同店销售额和同店交易额的增长预测,平均误差不超过0.7%。Thasos从大约1000个APP获取移动设备的地理位置,这些APP一般都是位置相关的产品,例如天气预报或行车路线。

大航海时代的全球人才竞争,两条史料

  里斯本国家档案馆记载,1627年3月6日,负责印度果阿的火炮生产的葡印商人,亲自就两名铸铁经验丰富的中国技师的行踪禀告葡萄牙国王,希望能够获得准许对关键工程技术人才予以优待。

  康华丽号风帆巡洋舰1812年在印度建造。总工程师Jamsetjee Bomanjee是印度人,出身造船世家,已是第5代担任首席造舰师(Master Shipbuilder)。30年后清朝在康华丽号上签署《南京条约》,Jamsetjee Bomanjee的儿子已当上第6代首席造舰师。

  可以对比之前提到过的,徐光启和戚继光时代的几何和火器。归根到底,最大的问题并不是武器制造,而是系统对人才和知识的兼容性。

共享单车和店面租金

  链家的数据分析很有意思:随着共享单车的出现,地铁口周边的不动产租金在下降,三公里半径的租金却在上升,逐步跟地铁周边的租金拉平。

  有一个反过来的例子,美国Thasos group利用移动数据对商业不动产进行金融分析。Thasos拥有一个高品质的手机位置数据库,从大约1000个APP获取移动设备的地理位置。拥有这个数据以后,就可以对商业地产的人流、销售、租金进行非常准确的评估和预测。

Tesla Model 3的生产率

  特斯拉产能爬坡,已经快变成娱乐事件了。马斯克又是换供应商,又是搬到工厂睡,又是大裁员,又是在大帐篷里搭建新流水线,又是怼投资人……来回折腾。

  Bloomberg有个叫 Tesla Model 3 Tracker 的页面挺好玩,开发的程序员是Tom Randall和Dean Halford。

  他们从各种网上来源,例如高速公路安全管理页面、社交网络、特斯拉用户论坛……抓取新增的特斯拉汽车的VIN(车辆识别码),估算Tesla Model 3的每周产量。此前曾有Tesla内部员工说这个数学模型估算的还挺准的。

  从下面这张图可以发现,此前几个月Tesla Model 3的产能一直在稳步上升。2月底的时候达到了每周917台,但是最近两周生产率突然剧烈下降,本周跌到了599台。到网上搜了搜,上周Tesla Model 3生产线升级,刚刚新增了自动安装电池的设备,还在调试中。

  7月3日更新:今天突然满屏幕都是Model 3产能终于超过5000台/每周的消息。查了一下,Q2共生产28578辆,交付18440辆。最后7天下线超过7000台(各种车型总和,不只是Model 3)。

GeneDock研发团队的一些方法论

  逼着自己上来写BLOG。最近工作强度非常大,回到家吃完饭洗完碗,真的手指尖都不想动一下。不过工作有进展,人有成长,心情还不错。今天冒着大雨回家,浑身湿透,但是心里一动:“两年前的今天我心情很糟,现在虽然累得像条狗,却很充实,看来这次创业是对了。”

  创业以来,感觉还算顺利。所谓好运气,部分源于GeneDock团队有一套自洽的逻辑。创业和投资说到底拼的是世界观,你对现实世界的某个局部有独特的洞见。这里面有些关于技术产品,有些关于团队管理,有些关于商务销售。

  这篇BLOG再总结一下GeneDock研发的方法论。算是呼应一年前的那篇《思考:如何开发应用平台》,对其做一些补充或再次强调。

一、彻底信仰API

  Alex Iskold说:“API代表公司的业务本质……思考API实际上就是思考公司的未来……”

  绝对赞同,一年多前我在社交网络发过一条对国内一些所谓基因云的吐槽:“不是做个Web页面就有资格叫云计算的。前端若不提供RESTful API、编程语言SDK以及UNIX风格的CLI工具包,后端若没有可拓展的分布式架构、防单点故障的failover机制……就别觍着脸自称云计算了,这只是一个网站而已”。这话似乎刺痛了某些人。

  GeneDock刚刚对外开放了第一批Workflow和Task有关的11个API。欢迎大家试用,这里是API-Reference文档。如果单从Web Service的设计这一点看,我们的产品领先于国内外友商。

二、To B 的产品逻辑:别抖机灵

  To B 产品和 To C 产品有很多业务差异。To B 是给专家甚至专家团队用的软件,本质上在卖你对行业的独特洞见,在卖你的工作哲学。例如,当年SAP的ERP软件最成功,因为他们最理解德国制造的业务逻辑;再如,Salesforce在卖的是销售团队的方法论;而GitHub实际在卖他们对软件工程的理解:Bug管理、版本管理、Code Review……

  另一方面,To B 和To C 其实都是给人用的软件。从设计和研发的方法论来看,并没什么本质区别。GeneDock产品经理何荣惠(在阿里云的时候程序员们昵称“神仙姐姐”)在知乎回答过“to B 的产品经理和 to C 的产品经理有什么差别?”,我觉得写得很好。

  总之。To B 产品,抖机灵没用,保持克制和敬畏。躬身入局,琢磨清楚基因数据传输、存储、分析、应用的所有业务场景。

  我们刚刚上线的企业账号功能,对很多团队都有用。GeneDock官方BLOG对此有描述,推荐大家看一下。

三、坚守软件工程底线

  GeneDock只雇用最好的程序员。好程序员必须能熟练应用软件工程的成功方法论。

  至于什么是好的软件工程,一年前都写过了:“好的软件工程实践,决定了技术团队的层次。Github用的怎么样、Bug管理怎么样、代码审核是否严格、发布升级是否自动化、有没有单元和集成测试……到一个技术团队里呆几个小时,鼻子闻一闻,就知道几斤几两。技术团队如果这些基本功不好,摩擦力会越来越大。”

  不只是提高自己内部生产率,GeneDock还想把数据生产的最佳实践推广到整个行业,成为生物信息行业的GitHub。我们正在优化配置和调试的体验,总结GeneDock生信团队的流程规范。后面会不断放出软件工程培训文档和配套工具,让生物信息程序员们效率更高,更专业,工作更有价值。

GeneDock架构师介绍分布式基本原理

  GeneDock首席架构师陈昕刚刚在公司网站上发表了一篇BLOG,介绍了有关分布式系统的基本知识,例如一致性问题、FLP不可能性原理和CAP定理。推荐大家看一看,了解客观限制,免得试图制造永动机。

  原文地址如下:https://www.genedock.com/blog/2016/05/27/20160527_distributed_system/

Max Levchin

  继续八卦,这次是Max Levchin。他是Paypal黑帮的关键人物,23岁的CTO,重要性仅次于Elon Musk和Peter Thiel。

  之前在《支付战争》的读后感里提过他。我又去翻了翻Founder at Work,原来第一章就是对Levchin的采访。其他信息来源包括维基百科,以及他在Quora上回答的问题

创业者  支付战争

  Levchin 16岁从乌克兰移民到美国,数学天赋极高。他擅长安全加密算法,所以创立了Fieldlink公司,想做移动设备的安全技术供应商。后来找到Peter Thiel当合伙人和CEO(Levchin只喜欢和聪明人共事,Peter Thiel小时候得过加州数学竞赛第一名)。Levchin对Paypal创业的回忆很少涉及那些著名的运营手段(直接给新客户10美元补贴等),也没怎么提Elon Musk和Peter Thiel之间的宫斗戏(稍微说了说Elon Musk逼研发团队改用Windows,结果导致政变),他讲得最多的是如何对付金融欺诈,这在《支付战争》里几乎没被提到。

  2001年Paypal因为信用卡诈骗每月损失1000万美元,而且比率还在不断上涨。这引起了团队的恐慌。Levchin自己一度有些绝望,然后开始全力应对。最终Paypal开发出一整套防欺诈的工具,称为IGOR。很多今天已经习以为常的互联网防欺诈手段,都源于那时候Paypal申请的专利。例如现在常用的CAPTCHA技术:多次输入密码错误后,会显示一张只有人类可以识别的图片,要求用户按照图片内容输入验证码,防止黑客利用程序暴力破解密码。

  按照Levchin的说法,竞争对手eMoneyMail就是因为无法控制商业欺诈,损失比率达到惊人的25%,不得不退出。而《支付战争》的作者似乎没有意识到这一点,他认为Paypal就是业务增长速度正面碾压了eMoneyMail,所以对方放弃了。可能两边都没说错,技术团队和市场团队不同的视角而已。Levchin评价《支付战争》总体还是很有趣的,虽然个别地方错误。

  感觉最近新闻很多的Palantir的技术框架应该就源于IGOR。Palantir是Peter Thiel投资的创业公司,利用金融领域反欺诈的大数据工具,帮助美国政府进行反恐,据说在追杀本拉登的行动上出了力。大名鼎鼎的棱镜监控系统获取的海量元数据,需要有合适的数据技术进行处理。

  Paypal被收购后,Levchin花了很多年创业做Slide,不成功,最后卖给了Google。他又回到最擅长的互联网金融领域做了Affirm。他在Quora回答在Paypal积累的经验对Affirm创业有何帮助:“People underestimate the complexity of legacy payment infrastructure. Solid knowledge of that helps a bunch. More broadly, the greatest lesson is always the same: people is what makes or breaks every company.”

  去年他又推出了Glow,一开始还以为是类似“好孕帮”一样的助孕APP,好诡异。仔细一看:”夫妇可在备孕时每月连续往这笔基金内存钱,每月50美元,连存10个月。如果10个月之后Glow还没能帮助你成功受孕,这个基金则会资助你后续的检查和治疗……Levchin把Glow的未来定位为一家健康保险公司。而现阶段要做的就是收集数据、改进算法,帮助更多夫妇成功受孕”。 牛,原来还是玩金融,这智商税太有才。

思考:如何开发应用平台

一、开发难度

  和创造单个应用相比,创造应用平台的难度要高一个数量级:

  1. 架构难度:和特定应用不同,应用平台是开放性的,允许别人到系统肚子里自主编程,因此应用平台的用户边界本质上是API。设计一套干净强大、可拓展、安全、完整自洽的API,并在此基础上构建SDK、Console、GUI……是很难的。进一步,为了支撑第三方开发,需要有编程工具链。尽管程序员们都会用编程工具,但即使是计算机系科班出身的程序员,90%也不清楚DSL编译器和IDE的实现原理。

  2. 产品难度:应用平台的产品设计,需要抽象和分解能力。不仅仅满足某个具体用户场景,而是必须把握各种应用开发者在各阶段遇到的各种问题。这里面除了用户体验、E2E场景、还得注意统一的设计哲学和必要的分寸感。没经验的PD往往忽视谨慎思考和设计,强调快速迭代和重构。对应用平台而言,指望靠蛮力代替深思熟虑,行不通。

二、成长周期

  关于平台何时成熟,存在一些客观规律:

  1. 平台真正“立”起来至少需要4年时间。看那几本回忆Unix、Windows NT、NeXT、AWS初创的书,例如G.Pascal Zachary写的《观止:微软创建NT和未来的夺命狂奔》,这些系统前4年都跌跌撞撞甚至反复重构。

  2. 第2年最容易死。BAT三巨头几乎同时启动自主云平台:阿里的飞天系统、腾讯的台风系统、百度的C++重写Hadoop计划。但腾讯和百度的团队在第2年的时候都挂掉了。事实上,阿里云差不多也在那个阶段经历了惊涛骇浪,只不过运气好,马云这个老板异于常人。

  3. 关键是团队的成熟。阿里云最重要的行业贡献不在于其本身的IaaS业务,而在于那支从零开始把操作系统做出来的技术团队。现在飞天团队很多牛人跳出来创业,如果还是做平台的话,就会知道哪里有坑。

三、方法论

  1. 发布的节奏感非常重要。从阿里云辞职,老上级点拨我:如果只做一件事,就是保持发布节奏。一个里程碑一个里程碑下来,现在是Sprint 18。真是做对了。虽然前面说4年才能成熟,但是不可能有老板真能容忍你4年啥业务也不扛。这就意味着,得向客户和业务团队承诺产出,一旦承诺了就必须说到做到。这还意味着,必须现实主义,收敛战线,降低阶段性期望,为支持业务做些妥协。衡量一个技术团队的基本标准,就是持续交付能力。

(Intel曾经遇到过困境,CPU浮点运算部件有错误,不得不召回,AMD弯道超车抢先推出多核CPU。可惜AMD无法保证稳定交付,结果又坐失良机。再往前,摩尔定律其实不是客观存在的自然规律,而是Intel的明确战略,给客户承诺的交付节奏,给自己团队戴的紧箍咒。在撞到纳米墙之前几十年,Intel一直说到做到)

  2. 时刻关注平台架构。保持低耦合高内聚,保持模块之间的正交。否则越往后越痛苦。尤其是客户业务接进来之后,如果边界不清晰,到处插管子,就死定了。要理解著名的Conway’s Law: A design reflects the structure of the organization that produced it。这条定律的意思是:什么样的团队组织结构,最终就会开发出一模一样的软件架构。如果有四个小组合作开发编译器,系统最终一定会长成一个四阶段编译器。所以大型软件组织内,在重构系统之前往往先reorg团队。

  3. 好的软件工程实践,决定了技术团队的层次。Github用的怎么样、Bug管理怎么样、代码审核是否严格、发布升级是否自动化、有没有单元和集成测试……到一个技术团队里呆几个小时,鼻子闻一闻,就知道几斤几两。技术团队如果这些基本功不好,摩擦力会越来越大。

  4. 问题是什么,永远比解决方案更重要。最常见的错误就是:拿着个锤头,眼里看来满世界的问题都是钉子。必须花很多时间深入思考:客户有什么问题?我们能带来什么改变?逐渐建立对这个领域的独特洞见。

(仔细读了读巴菲特创业最初10年的信。他先建立了自己的独特benchmark,然后把投资对象分为4类,每类有不同的触发条件和行动。)

  5. 找到issue优先级明确roadmap才能减少焦虑。能砍事儿的才是合格的产品经理。做了太多客户不需要的事,团队总是加班,这是管理债,是耻辱,不是骄傲。

(讲到这里,顺便贴一篇两年前给pFind组的回信,最近Boss H又翻出来抄送给pFind团队)

  我已经离开pFind很长时间了,不了解细节。说错了大家拍砖。憋了好久,没憋住,因为pFind始终是我的产品。

  所谓战略,是明确不做那些“比较对的事”,只做一两件“非常对”的事情,壮士断腕才能做好产品,好产品才有资格进一步谈平台化和生态系统。

  客户需要精确的结果,客户需要飞快的速度,客户需要傻瓜式的安装和参数配置,客户需要全流程解决方案,客户需要在平台第三方开发的API和SDK,客户需要易用的界面、配图和表格……不从前面这些需求里砍掉90%,集中精力把剩下的一两项做到全世界第一,就没意义。

  不如每个人列两个单子:你认为pFind最该做的事,最该放弃的事。别写很多所有人都同意的真理,信息熵为0。如果为了防止互相影响,就单独发给BOSS H汇总。

  恕我直言,所有界面类的开发工作,pFind组都很不擅长,做得很苦、做得很烂。我们这些人离顶级UED差得太远,也未必有热情追求用户体验的卓越。也许更应该集中做算法、做流程框架、设计数据接口和API、向外界开发者提供API和SDK(这里的API也许是本地的,也许是Web Service)。至于界面也不是彻底不做,现有界面可以重构到前面说的API和SDK上去(以便吃自己的狗食,验证API、SDK的设计合理性)然后再开源出去。

四、BD和运营团队

  传统背景的业务人员面临挑战。因为他们要花一些时间才能意识到:推销的是通用平台,而不再是某种具体应用。

  1. toB销售,又面对专业技术话题,业务团队需要配备得力的业务架构师(BA)帮助技术交流,给解决方案。

  2. 找来了很多客户,仔细聊下来,有一半其实是需要Word(应用),而不是Windows和VC++(平台)。早期应该组建专门的技术小组,自己扑上去帮客户开发应用,也算吃自己的狗粮。后期再逐渐找外包商和集成商。CEO说,友盟的前70个客户,都是友盟自己的程序员扑上去帮他们写APP。

  3. 平台是前所未有的东西,是改变现状的创新。所以业务团队的目标不是销售数字,而是尽快立起标杆客户。

  4. 业务团队需要了解技术团队的发布节奏。知道有“水面以下”工作量存在,例如产品架构设计,例如重构偿还技术债。这些最终会影响到技术团队的持续交付能力。

  5. 业务团队有权要求更多后方的火力支援,理直气壮扯着产品经理的耳朵大喊客户需求,明确业务优先级,并监督技术团队的产出。

  6. 最终,其实和技术团队一样,业务团队最大的挑战还是学习能力,建立独特的思考模型。

成长和决策

  创业以后就变得紧张,有时候睡不着觉,没有心情更新博客。其实工作量还好,GDers大都是出色的工程师,团队也采用了成熟的软件工程,尽管工作强度很大,却不太加班。

  紧张是为个人能力不足而焦虑。真刀真枪开始创业,挽起袖子一个个PK问题,以前养成的粗心和懒惰的坏毛病就跳出来了:竞品调研不深入,代码review不仔细,琐碎管理没耐心、文档和邮件拖延症、人际交流疏忽大意……运气好,合伙人和团队都是顶尖的,同伴互相帮忙扛了很多事。但是团队在进步,跟不上,你自己就是瓶颈。

  刚去德国休假调整了一下,静下来仔细想了想。接下来得更勤勉努力,也需要更有效的沟通。关键是执行!关键是执行!关键是执行!(重要的事情说三遍)。希望自己还能不断成长。在BLOG这里把当下的心情记录一下,日后印证。

  放几张德意志博物馆的照片,这里被称为“工程师的卢浮宫”。

  再聊聊决策。

  上周去计算所参加了一次创业沙龙。做了一点分享。除了介绍我们的产品,还聊了聊创业本身,尤其是关于决策,内容整理如下:

  1. 无论做什么事,关键都是决策和执行。
  2. 所谓高效的决策,就是在有限的时间内,凭借有限的信息作出正确的选择。这里面有很多重大选择,短期看无所谓好坏,然而涉及长远目标的取舍。
  3. 时间信息有限的情况下,要是没有一套自己现成的逻辑,就成了赌博,决策质量不会太高。
  4. 逻辑或者说方法论,源于系统化的阅读、交流、试验、学习和思考。
  5. 诺贝尔获得者那本《思维,快和慢》讲的就是这件事:人类的大脑有两种思维方式,一种是逻辑思维,很慢很费能量,但能应对复杂场景;还有一种是感性直觉,很快,但几乎是最原始的神经反射。系统很懒,总是不自觉地就切换到“省电模式”去了。而且关键时刻,在压力和情绪作用下很难静下心思考,往往是直觉占上风。正确的直觉并非天生,源自大量的自我训练和经验积累。
  6. 搜索引擎有离线和在线两套系统,离线系统很慢,但是负责抓取全网的数据,build索引。而真正查询过来了,在线系统直接查找索引,几句if else if else就快速返回答案。
  7. 平时对一个主题不涉猎没概念,没有构建牛B的索引,事到临头指望灵光一现,往往会进退失据。所谓机会给有准备的人,我在团队招聘时感触很深,很多人真的不懂创业,同时也没想清楚自己能做什么,想要什么。
  8. 在创业这件事上,很多朋友很有热情,但表达出来的逻辑很浅:迭代改进、不怕失败和挫折、独特的点子、找用户体验的痛点、点灯熬油加班拼搏……总之,基本来自网上鸡汤段子和《乔布斯传》的片段,却缺少详尽的调查和学习、深入独立的思考、清晰的自我认识、与众不同的洞见、以及细节上的取舍决策。
  9. 指望用蛮力代替深思熟虑,这不靠谱。读万卷书,行万里路,把精力集中在长远目标上,把自己训练成领域专家。
  10. 我选择厦戎这个老大,就是因为他的决策质量非常高。

  叭叭呜的知乎专栏最近有一篇文章,讲述了Segway公司早期和乔布斯的交流。 即使交流对象是乔神这样的偶像,没有独立思考和逻辑,被对方洗脑,也是很危险的。Segway这件事里,即使乔布斯说得全对,他们也许还是应该咬着牙继续坚持原有节奏。而不是丧失信心推迟发布计划,甚至要“做出一款让乔布斯尿裤子的产品再发布”(注意,连语言表达方式都被乔布斯影响)。

谈谈ODPS商业化(五):华大基因在ODPS上做的试验

  这篇BLOG是ODPS商业化一系列文章之一,更多请点击这里……

  由于我正在着手做生物信息云计算方面的工作,很多信息不方便透露,这篇会很短。有兴趣的同学请找我线下交流。不过在阿里云上做基因测序创新的同学们不必担心,阿里云没有野心、也没有能力成为一个提供完整基因测序计算服务的公司。相反,ODPS等等产品一定是做底层通用平台该做的事,帮助生物信息应用上云更方便,和创业者们一起成长。

  回来开始说华大基因在ODPS做的试验。以前写过一篇博客提到过这件事。

  将基因测序仪输出的上亿条DNA片段拼接为基因组长序列,这个过程可以看作在一个超大规模的拓扑图上寻找欧拉路径。人类基因组包含30亿个碱基,目前基因测序一般会做30倍到50倍的扩增。利用典型的单机组装软件至少需要256GB的内存才可能完成基因组装,时间长达数天。

  ODPS Graph Task是面向迭代的拓扑图算法处理框架,提供类似Google Pregel的BSP并行编程模型。正适合支持一些超大规模拓扑图算法。

  去年10月5K项目测试期间,华大基因的生物信息专家基于ODPS Graph Task开发了一套基因拼接算法,在E.coli(大肠杆菌)、Bombus(熊蜂)和Yanhuang(人类)三个物种的测试集上均取得了非常高的加速比。

  此前一直关注Google在生物信息领域重兵投入。自从Google Genomics API推出,形势就更加明确了。另外一边,据称亚马逊AWS美国有1/4的客户来源于生物制药行业。生物信息显然是云计算的重要业务增长方向。随着全球第一张基因测序临床牌照的颁发,已经可以看到国内大量围绕基因测序的创业项目起来了。目前ODPS团队正在和多个生物信息领域的合作伙伴一起努力,把各种生物信息经典算法和数据处理流程搬到云上来。如果你正在做这方面的产品、创业,欢迎和我联系,阿里云会尽可能提供关键帮助。

  另外我刚刚在知乎和知因同时发起了问题:生物信息还需要云计算提供什么样的功能?生物信息应用上云,你碰到了哪些问题?现有的阿里云、亚马逊AWS云计算基础设施需要做哪些改进,为什么?目前你用的最多的云产品和Web Service API是哪些? 等待你的真知灼见:
  知乎:http://www.zhihu.com/question/24719395
  知因:http://www.knowgene.com/question/1639

  这篇BLOG是ODPS商业化一系列文章之一,更多请点击这里……