外设的视角

前几天看到onlycoin的时候,有种这么久了,终于有点新鲜点的思路的感觉.

稍微浏览了下描述,本质上其实就是个复制银行卡信用卡等信息东西.
只不过是把这多张卡集中到一张卡上存储而已.

这个本身不是什么很激动人心的东西.
倒是这个集成卡的思路可以发散下.

毕竟,这个至少解决了卡太多的问题.

但是细想一下的话,其实还可以更丰富一下.
或者说实现上更优雅一些.

毕竟,直接复制卡这一点,总觉得不算是一个很好的解决方法.

一个可能更折中的办法是自己发行一个信用卡,或者依靠银行发卡.
然后实际以这张卡消费,再通过一些协议跟back的其他银行卡和信用卡做对应的对账和销帐.

技术上来说,应该算是以其他银行卡和信用卡作为资产抵押的一种抵押卡吧.
或者说是信用代理.

这样的话,不仅可以给使用者提供一个unify的用卡体验.
更重要的是,实际的交易是经过自己发行的卡的.

换句话说,这里就比较微妙了.

技术上是可以得到所有经卡交易的明细的.
毕竟,第一步的交易对账是发生在这张unify的卡上.

于是,买了什么,消费了多少,刷卡频率这些都可以简单地统计和收集进来.
再进一步,对交易的卖方做一些统计和整理的话,也可以比较轻松地得到消费地点,类别等信息.

将这些信息做一下配对的话,也应该比较容易地可以得出一些消费的高频发生地点,以及某些地点的大致消费水平.
也就是说,可以得到一些地方的消费特征.

而有了这些信息的话,反过来做线下营销和平面广告的话,可能就更有一些针对性了.

加上有了消费习惯的数据积累的话,对一些季节性的消费行为就可以比较直观地了解到.

预先能够得到一些消费序列的话,那么在销售上就可以把整个序列作为一个商品来考虑了.
这样的话,就可以考虑类似规模效应的策略了.

单点的盈利高低不再那么重要,因为可以从整个消费链条中摊平.
增收的点就在于如何让这条链条变得更长,或者说,激活潜在的消费了.

当然,能做到这些的也并不是完全因为有了unify的卡.
但是,能把线上和线下数据,尤其是跟交易消费相关的数据结合起来的,大概也就只有类似的思路吧.

目前的移动支付的话,还只是专注在怎么把支付从PC延伸到mobile上.

某种程度来说,还是属于一种"经验"迁移的过程.
把已有的模式,放到新的平台上面.

纯粹的平移的话,交易内容其实还是基于线上的产品交互的.

一些离线的交易,也只是通过一个代理的方式,转换成线上交易.

换句话说,其实还是以online的方式桥接offline.

但是,从所谓移动互联网的趋势来说,online和offline,现实和线上的差别其实是渐渐模糊.
或者说互相融合的.

这个从smart phone的普及,以及平板概念的复活就可以看出.
人是越来越离不开互联网,但是又越来越不需要"显式"地留在互联网.

这个就要求互联网的一些功能尽可能地日常化,后者说物化.

这大概也就是一些诸如Glasses/Smart Watch之类的便携设备概念兴起的缘由.
所谓的真正意义上的外设概念.

所以,按照这些思路的话,unify card也算是一种支付方式的外设概念.
它跟现在的手机支付的区别在于,看上去很传统,但是实际上包括非传统的部分.
线上和线下消费可以透明地结合在一起.

手机支付如果需要涉及线下的话,至少需要一种机制能够正确地识别商品价格.
或者说,能够从非标准的环境中,完成标准化的账户交易.
比如QR code里encode了完成支付所需的信息,以方便通过普通网络完成交易.

又或者商家能够便携地生成支付信息,然后让买家完成支付.
而这个,其实跟unify card就没什么区别的.
因为这个支付的生成工具本质就是类似POS机的东西.

所以,实际上,网络跟现实的交汇点其实并没有想象中那么少.
有时候可能只是因为缺乏一些另外的视角罢了.

所谓"外设"的视角.

某种程度上来说,也是一语双关了.

浅谈AngularJS

最近为了麻痹自己或者说转换心情,把以前写的一个东西重新翻出来重写了一下.
由于涉及到一点配置页面,于是顺手研究了下AngularJS.
因为本来也是自己手写的页面跟数据的绑定联动,刚好AngularJS主打的特点就是这个.

稍微翻了下Angular的文档,感觉还是挺舒心的,虽然不一定使用.
但至少,很简明扼要地说了大概原理.

尽管,在翻看实现前,光看这些描述,带来的问题估计会比看之前更多.

还有一点就是概念比较多.
比如model,module,scope,controller,injector,service,serviceprovider等.

而实际上,浏览下来,比较核心的也就是injector和scope这一块.

injector的实现算是比较奇巧淫技的.

简单说就是把函数tostring之后,从字符串里提取参数.
然后通过参数名字查找相应的对象.
最后在apply回去,实际调用函数.

这个过程angular称之为annotate.

方式其实不算复杂,思路也很清晰.
只是,不说的话,一时半会未必想得到这么做.

而且它的一个问题就如同在注释里说的,一旦遇到对scirpt做minify的时候,就可能会比较麻烦了.

还有一点就是,如果按照正统的bootstrap方式的话,其实是在调用bootstrap的时候,一次性将所有module注入的.
换句话说,如果你module比较多,且可能加载比较耗时的话,即使页面load很快,但是渲染也会被拖慢到全部加载完成才开始.

当然,这个只要把它的bootstrap的实现自己手工展开一下也就可以分批load.
某种程度上来说,也就突破了单页面单个ng-app的限制.

因为这种方式,其实是不用ng-app的.
需要的是手工选择module绑定的节点,$compile一下,然后apply相应的scope即可.

而scope正是angular宣扬的two way binding的核心所在吧.
简单地说的话,就是ng/directive/ngEventDirs.js那里不到十行的代码.
把一些有用户交互的事件绑定到了scope的$apply上面.

也就是说,任何用户对页面元素的操作,都会出发$apply函数.

而apply函数的作用就是触发$digest,去检测绑定的model的所被watch的部分.
如果有值的改变,就触发dom的修改.
以此实现two way binding.

但是这里有一个问题.
就是这种binding,必须是一个元素触发另一个元素的修改.
而不能是自己触发自己的model view synchronize.

比如说,一个值绑定了一个input元素.
那么,在这个input里输入的时候,一般是不会触发起所绑定的值的变化的.
而如果通过ng-change去同步两者的值的话.
那么,由于angular的机制,每一个键盘敲击动作都会触发$digest,从而引发dom/view的更新/修改,从而中断交互.

一个解决方式就是对这个值做两份copy,一份用于view的显示,一份用于view修改时的真正的binding value.
但这样其实就退回了手工维护two way binding的情况了.

所以呢,angular在这点上还是有略显遗憾的地方的.

当然,大多数情况下下的交互都不需要这种自身修改然后马上反馈回来的机制的.

简单来说,去掉现成提供的各种directive的话,angularjs的其实还算简单的.
或者说,核心不复杂.

好的设计就是,说出来了觉得简单.
但没人告诉的话,也许就想不到.
所谓精妙.

Bad & News

其实很大程度上来说,会动手写点近况也是因为想到了这么个略显取巧而有意思的题目.

离开北京到深圳也有相当一段时间了.

也许是年纪的问题,也许确实是城市的差异,感觉深圳确实算是一个可以定居下来的城市.

至少交通是通畅的,空气是可以接受的,接触到的也算平易近人.

不好的可能在于企业和文化方面.

相比北京来说,套句恶俗的话说就是没那么高端大气上档次.
毕竟,这里多是劳动密集型产业.
即使是号称互联网的公司,思维模式其实也是很脱离时代的.

或者某种程度上来说,也许它们才是真实的中国互联网生态.

很朴素的勤奋和时间换取成功机会的思路.
做的,确是模仿,复制,"信手拈来"的事情.

对于互联网的行业的认识,大概是留在敏捷和所谓快速迭代的印象上.
翻译回来可能就是加班和改动多.

对此,也只能笑笑了.

一来,这是自己的选择,或者说已经没有选择.
就像之前收到的没有下文了的Google HR邮件,以及没什么成果可谈的Amazon机会.
机会可能更多时候是一种错觉.


二来,其实也没什么嘲笑或者蔑视的理由.
毕竟,从逻辑上来说,这种思路并没有致命的缺陷,使它构成失败的必要要素.

而在生活方面,则比北京愉悦多了.
在大体相当的支出情况下,食住行方面的质量,可以说是有个比较大程度的改善.

更主要的,可能还是因为多年难见的朋友终于又在一个城市了吧.
想想高中以来,也差不多是十年的时间了.

说到底,多是一些心理和生理上的不适吧.

比如一周工作6天.
虽然在北京的时候,无论周末节假日都在公司,但是自愿和非自愿的差别还是有的.

比如用上了MacBook Air.
之前在被问到该给大家配置什么设备的时候,说了默认Air,可自选.
但实际到来的时候,却发现只有仅有的几个人是如此,其他都是区别对待.
看到这个的时候,说时候,印象大有折扣.
毕竟,这不是希望且愿意看到的.

比如遇到"这很容易做"的完全不懂技术的产品人员.
比如见识了言必SSH的高端Java人才.
比如接触了大名鼎鼎的前阿里云技术转产品人员.
比如领教了还没确定核心功能就在讨论页面展现和交互细节的产品负责人.

比如重见了开了4+小时的毫无结论的会议.
每每这种时候,就会额外想念以及敬佩曾经的教授Joshua以及它对会议主线的把控能力.

诸如此类.

有时候觉得,应该否定掉自己的这些看法.
有时候觉得,应该否定掉别人.
有时候觉得,应该否定否定.

有时候觉得,这些纯粹是自己隐隐的莫名的优越感在作祟.

毕竟,生活在继续.

纠结自己或者纠结别人,意义都不是很大.

毕竟,世界是个相互影响的不定系统.
一方的决定和行动效果,其实没有自己想象地那么容易约束不发散.

真地和预想一致了,那不叫远见.
而是运气.

这大概就是国内A股的一个价值所在吧.

偶然的相关性

某天某人提出想用FastDTW做一些已有统计数据的相关性计算.

FastDTW算是DTW的一个优化方式.
而DTW简单来说,就是计算两组数据的所有组合方式,然后找出一个cost最小的数据X->数据Y的映射关系/路线/矩阵的对角路线.

当想到映射这个词的时候,有种豁然开朗的感觉.

所谓两组数据存在相关性,也就是存在一个变换T,使得Y=T(X)成立.

简单假设这个变换是线性的话.
那么两条曲线是否相似的问题就转化为,线性拟合后的曲线T(X)与Y的误差是否在合理范围内了.

所以,简单地对各条曲线做两两组合的线性拟合,然后看方差就大致可以得出那些曲线是存在相关性/联动的了.

更进一步地,曲线间做个相对序列平移的话(比如X[:-1]与Y平移4位后的Y[4:-1]),也可以做一个类似"因果"关系的拟合.

问题是,由于各组数据间的数量级不尽相同,直接的方差比较就没什么太大的意义了.

一个思路是对方差做normalize,使其规约到同等范围内.
另一个思路是直接对源数据做feature scaling.

对前一种思路并没有想到很好的方法.
直觉上应该都是需要跟源数据/期望做一些运算得出一个相对的scaling function/mapping/transform的.

这样的话,不如直接最开始就采用后者.
而且这个也有比较通常的做法.

对于给定数据X,简单的(X-mean(X))/std(X),源数值减去均值,然后对比标准差做个缩放.

而且由于前提假设是线性换掉拟合,因此,对于任意两组数据,X,Y,scale之后跟之前的差别不过再多一重线性变换而已.
因为mean(X),std(X)都可各自认为是常数.

于是,保证了变换后进行拟合的合理性.

剩下的就是蛮力地对所有可能的组合进行拟合比较方差了.

实际的实验是拿了大概200组各游戏的30天日统计数据.
也就是每组数据大概30个值吧.
组合之后,排除一些无意义的组合(自身跟自身,前后排列重复的),大概就剩下17k左右的拟合结果把.

随意选了一些方差小的来看,结果其实挺尴尬的.

比如有一个结果是某游戏的累计MAU(monthly active user)和另一个游戏的DNU(daily new user).
前者是个每天累计的值,原则上来说是每天递增的.
后者则是一个浮动值.

对于这个结果的解释,大概就是恰好DNU一直在下降吧.
于是就不小心负相关了.

而一些数据则是比较正常的.
比如某游戏的各地区汇总DAU和某主要地区DAU之间的正相关.

所以说,相关性这东西,只能说可能存在关系.
false positive的情况还是比较普遍的.

对于不能解释的相关性,如果硬要拿来作为决策的依据的话,感觉跟掷骰子赌一把没什么区别.

一个简单的例子就是,每次下雨的同时说一句要下雨了.
那么从数据上来说,下雨和说下雨是相关的.
而以观察某人是否说下雨来预报天气的话,多少显得儿戏.

尽管,严格来说,这种"气象预测"是准确的.
因为确实每次说下雨的时候都在下雨.

但矛盾点在于,它颠倒了因果关系.

虽然,用前面的话来说,通过一些平移可以做一些"因果关系"的拟合.

不过始终的,相关性只是说明了一个结论.
对于发生的过程并没有任何信息.

从科学的角度来说,相关并不一定是可"准确"重现的一个结论.
能不能有效,多数时候是"运气"使然.

所谓偶然的相关性.

所谓收敛

之前一直觉得互联网之于个人来说是无限的.
毕竟现在几乎所有东西都能够通过网络访问.

但是打开chrome看到最近访问的时候,才醒悟过来,可能并不是这么简单直接的逻辑.

虽然每天可能访问着各种不同的链接和内容,但是,细想之下,其实起点都是个有限集.
所有内容不过是非常有限的几个地方展开的.

与其他普通链接不同的是,它们自己算是一种某种程度上的平台,或者说协议.
比如email,比如rss,比如tweets,比如某些视频站,比如某些论坛.

虽然看上去有着各种不同的内容和社区准则,但实质作用不过是导入一些具有鲜明特性和分类属性的链接.

某做程度上的对graph的partition,或者说某做mapping或者transform.

于是所谓的导航网站的意义就很明显了.
一个structure的特解,减少的借入构造成本.

把这个应用到移动方面的话,似乎也差不多.
毕竟这是本质需求.

所谓获取信息的成本问题,加上本身现有移动环境下带来的交互限制.

尽管,平板之于手机的话,可能更类似于传统的桌面web环境.
但不可否认的依然是操作交互上存在天然的局限性或者说区别.

抛开这些,另一个问题在于,app的迁移成本.

传统web在具体到各个网站和服务的时候,也存在迁移成本问题.
但相较于web来说,问题可能相对简单些.
毕竟,多数时候,只是替换一个link而已.

而app的的特别之处在于,除了自身服务的迁移成本以外,还有替换app的成本.

考虑极端情况下,一个移动设备只能安装一个app的情况.
在这种情况下,后来的app如果想要提出旧有app的话,难度无疑比web服务的替换要打得多.
web服务至少还可能同时使用,但移动环境下的app可能就会受限与物理因素,使得连尝试的入门成本都变得异常的高.

换个角度看的话,就是app的lock down作用非常地明显.

于是,加上web固有的,人只需要少数入口/协议的观点,在移动平台的交互没有大的革新的前提下,所谓平台的价值将会非常明显.

这里的平台可能并不是一个传统的诸如Facebook之类的载体.
它可能只是一个具有相对连续性的东西.

即,即使app改变了,它依然存在.

比如twitter类的关系,即使客户端变了,但是本质服务的内涵不受影响.

所以,从这个层面来说,平台的含义指的是这种不可变的连续性.

于是,如果这个想法是对的,那么可以预见的未来将是更多的以协议为基础的交互.
比如新闻阅读类回归RSS,视频类衍生类RSS的交换标准.

毕竟,如果市场是竞争的,那么必然会有层出的竞品出现.
而如果竞品足够优秀,那么就意味者会有不断的安装和卸载事件发生.

如果不是的话,由于lock down效过,进入门槛将会变得不可想象地高,使得市场只留下有限的几个参与者.
而一旦形成这种垄断局面的话,也很容易地会催生相应的协议,以使得小参与者们能联合起来形成规模效应.

于是,无论怎么看,最终都将会衍生一系列的交换标准以帮助和保证市场及其公平性.

Schedule

前段时间用go把zeromq和leveldb粘合在一起,写了个玩具性质的queue(http://goo.gl/m3anm).

于是,一个纠结了很多次的问题又出现在了眼前.

站在API的角度来说,zeromq和levelddb都是可以异步的.
于是,使用上的一个问题就是,如果全部采用异步接口,那么就存在一种情况,所以调用都没ready的情况.

这时候,要么自己sleep一段时间,要么burn CPU.
就像没有epoll之前,如何使用poll一样.

所以这个问题的矛盾之处在于,异步或者说time sharing的目的为了用尽可能少的资源,做尽可能多的事情.
也就是减少浪费.
而,一旦出现某个时期,所有工作都是闲置状态的时候,却多数不得不做稍显浪费而又必须的loop/poll.

出现这个问题的本质原因,是站在上层角度来说,没有像系统一样的来自外界的唤醒重入机制.
像epoll,可以由外界的硬件通过信号触发处理例程的重入(尽管实现上,并不确切,但至少理论上是可以让CPU完全闲置,而不会有什么副作用的).

于是scheduler需要的是一种离开block状态的通知机制.

这个通过把schedule注入到signal handler里也是可以实现的.

问题是,不是所有的可能block的地方,都存在这种ready状态的回调.
因此,多数情况下的选择就是burn cpu了,所能做的优化只能是尽可能减少无谓的poll,同时尽可能降低调度带来的延迟.

毕竟在这种情况下,要么是poll早了poll多了,要么就是poll晚了.

目前go的sysmon的做法是采用2us的幂次增长,最多10ms的延迟调度,外加一个对网络的poll.
以期望尽可能地实时调度.

这算是一个很工程化的解决方法,能解决一部分问题,但不根本.
因为它依赖于这个间隔时间的调整.

事实上,许久之前自己也写过一个类似的东西(http://goo.gl/8ymEZ).
它的其中一个问题就是调度周期带设定.
尤其是面临一些繁忙程度比较浮动的情况.

而且,对于再上层应用的应用来说,就算go本身提供了这种机制,并且能够良好工作,自己写的时候也一样会遇到类似的情况.

就像开头说的,如果应用本身都是异步的,那么自身也需要有调度.
比如zmq_recv完了,发现没东西,那么可以直接一个goroutine出去.

在多数情况下,这个没什么问题.
但是如果其它goroutine也是这样的不ready状态,那么无非等价于一个空的for循环.

这里能想到的就是引入一些本身有block属性,同时能触发调度的.
也就是chan.

之前尝试过在for里加gosched,效果没什么改善.
因问题的本质是空闲造成的,gosched的结果不过去取出下一个空闲的goroutine而已.
做一些看似有用实则差不多的事情.

当然,如果都是纯粹的go code的话,也许不需要.
因为go"保证"了所有时刻都是在有效率地消耗CPU.
毕竟,任意go,或者chan等逻辑上的block操作都会触发调度.

但是遇到syscall以及cgo的话,就可能不太一样了.

cgo本质上都是syscall.
而syscall的问题在于,它会让出当前的P,然后调度器会为此多一个M去执行go code.
也就是,syscall的后果就是,多出一个worker线程.

虽然原则上来说,只有非常频繁的syscall才会导致线程数异常增长.
而且,即便如此,也可以通过lock或者buffered channel等限制syscall的并发数量.

但这个跟这里的问题关系不大.
cgo在这里的问题是,如果你的go code(main)跑完了,那么整个程序就结束了.

所以,这就要求go code里有一段"永远"block的调用.

如果是永远block的调用的话,对于默认单P/逻辑M/逻辑线程的go来说,就是以后都没有可用P了.
于是,即使cgo返回,由于没有逻辑上可用的P,程序也不会继续下去.

因此,它需要的是一个带yield的语义的调用.

这个yield,回到前面的话题,就是要考虑怎么尽可能不浪费而又实时.

于是,只要有着尽可能有效利用的想法的话,就逃避不开调度这个问题.
而多数情况下,都只能有很工程化的解.

Bitcoin的理想主义

最近看到貌似不少自由主义倾向的人对bitcoin的去中心化,以及可能的经济变革颇为推崇.

于是又重新考虑了下这东西.

一个比较容易解决的假设就是,如果现在马上把货币切到bitcoin的话,那么必然的所谓的经济系统就完全瘫痪了.
因为有人没有bitcoin,因而就没有了发生交换的筹码.
也就是说失去了经济金融能力.
用个可能不确切,但足够表达的词就是奴隶.

当然,这是一个极端的情况.

那么考虑,将现有货币替换为bitcoin.
这样的话,看上去大家的财富都没有明显的变化.

但是,当发生交易行为的时候,就有可能出问题了.

考虑,如果交易是不等价的交换,那么必然存在一方有交易利得.
比如某人以A价格买入物品B,如果物品B的市场价格C大于A的话,那么也就意味者买入者可以通过再次卖出获得A-C的收益.
而由于bitcoin的总体数量存在一个理论上限,并且生产速率随着现量的增加而递减.
那么就存在一个时期,在这个时期内bitcoin的数量可以认为是恒定的,而同时由于存在不完全等价的交换,使得bitcoin存在一种从一部分人向另一部分人单向流入的状态.

换句话说,就是从宏观看,在这种情况下,bitcoin存在一个天然的贫富不均的态势.
理论上,会回退到一部分人几乎完全没有bitcoin的情况.

一部分人的财富正增长意味着必须有一部分人的增长是富的.
由于bitcoin的零和属性,这几乎是必然的.

当然,这个的前提在于不等价交换的存在.
理论上,如果能够让每个交易都等价.
或者,每个个体从总体上来说每次交易都是等价的话,比如一次低于市价而另一次高于,那么财富的定向流动也是可以避免的.

然而,换句话说,就是每个人的财富都是固定不变的.
这个的话,也不能说是不可能.

考虑人口正增长的话,要让现有人口的总体财富不变,也就是要求人口的增速低于bitcoin的增速.
不然的话,就存在一些人因为人口的增长而使得财富减少.

问题在于,如何保证每个人的财富总体上是保持不变的?

在现有经济体系下,个人的财富是与其工作回报有关.
而bitcoin的经济系统要求每个人的财富总体恒定.

那么对于,不工作的人,系统也必须为其保证财富的恒定性,不然就会导致财富的定向流动.

当然 也可以允许存在这种自然淘汰目的的豁免.

但,对于努力工作的人来说,其财富也无法增长.
或者,名义增长了,但是制度要求其进行相应增量的消费,以维持财富的名义恒定.

这种强制消费是系统要求的,但又不是系统自身能够保证的.
那么,要让系统正常运作就隐含这某种强制监督"机构"的存在.

这种机构可以是真实的机构,亦或者只是简单的有有效期的财富配给(比如这笔钱的有效期至某日前).

但不管怎么样,总地来说,一个人的财富跟其努力程度已经无关了.
也就是说,在这种前提下,系统是没有所谓激励的说法的.
而社会的进步依靠的则是不求回报的一帮人.

这点,倒是让人联想到了,生产力高度发展,人民群众按需分配的所谓终极理想制度了.

依靠个人的自觉去推动社会的发展.

而在允许优胜劣汰的财富定向转移的前提下,社会的构造将是普通人和自觉的精英.

一个无所谓贫穷富裕,纯粹兴趣驱动的绝对乌托邦.

问题是,谁来提供这种保证,使得bitcoin经济能在这些约束条件下稳定运行?