外设的视角

前几天看到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的其实还算简单的.
或者说,核心不复杂.

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