外设的视角

前几天看到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经济能在这些约束条件下稳定运行?

时间的回归

Google要关闭Reader了,于是RSS已死掉调子又被重新提了起来.

其实死的不是RSS,而是互联网的精神吧.
至少是某一个时代的互联网精神,即使它肯能已经不为时代所用了.

RSS作为一种公告协议,提供的是内容的无缝聚合.
换个角度来说,其实RSS是某种程度上的内容平台.

当然,或许内容垄断更适合用来称呼这种主导地位.

在RSS面前,凡是以内容为核心的网站,不可例外地被统一在RSS背后.
而,对于RSS阅读器来说,这些内容制造者的影像最终也就剩下内容本身.

所以,如果退回去看的话,其实某个时代还有过RSS扼杀了内容这种说法.

这也是为什么会有摘要RSS的出现,为什么会有Feed内广告的存在.

不过是屈服于平台下的让步而已.

所以,从商业角度来说,RSS并不能为内容产生者带来更多的什么.
没有剥削已经是很仁至义尽的了.

对于Reader这种RSS阅读器来说,它没能创造出新的商业价值,却不可避免地不同程度地损害者内容提供者的利益.

尽管,对于内容产生方来说,这种损失其实很难估计.
因为纯粹的流量并不代表什么.

但,至少,没了流量,就少了一个可考虑的思路.

无缝的互联网对于用户来说,当然是最好的.
因为它意味着廉价,便捷,对等,以及主导权.

网络的一切都在使用者的手上自由组合演绎.
每个人都是这网络的上帝.

但是,谁来为这种权力买单呢?

尽管,有人生产的内容只是为了分享,而不是具体的可考虑到商业收益.
但是,如果这类人不能达到多数,那么,谁去供养这种权力呢?

所以,现实是,即使现在的网络结构越来越具体化,长尾使得任何一类人都能找到相似体,任何一类内容都能找到读者.
但是,这并没有否定个体之间存在共性.

他们有共同点资讯需要,共同的搜索需求,共同的娱乐方式.
即使不是普遍意义的共同,但至少也是一个相当巨量人群的同质需求.

如果这些消费者能够自己产生内容供养自己的话,这不会有什么问题.

关键在于,多数人多数时候在多数场合都只是单纯的消费者.
如果一个人能满足自己的所有需求,那么社会就没有存在的必要.

于是,专门的内容提供者就成为必要的存在.
而必要性本身就意味着需要用一定的价值去换取.

而商业化是最普遍的逻辑.

从这个角度来说,RSS即便没有对内容的可持续增长做过实质性的帮助的话,那么至少起到了一定的阻碍作用.

所以,Google关掉一个无法做贡献的产品的做法合情合理.
况且,本来就已经有更商业友好一些的Currents.

只不过,对于用户来说,这条路变得更被动一些.
毕竟,原本自己便是编辑,而现在,只能是纯粹的读者.

但这种"被动"真地算得上一种损失么?

或许.
因为去熟悉和接受新的方式,改变现有的生活,多少是有些让人不太舒心的.

但至少,它带来了变化的可能.
虽然并不一定向着好的方向变化.

除了流量可以做交易外.
时间也可以尝试.

无解的房价

今天看到对二手房征收20%差额所得税的消息,在某群里略微谈了下,感觉可能会起反效果.
毕竟这是可转移的成本.
不管高房价是什么原因,只要没有达到承受上限,最终都可以被消化掉.

实际上,这个所谓承受上限多数时候是没什么意义的.
只要小于人均一生的可支配资金数量,那么就还会有上升空间.

价格的变动通常是受直接的买卖双方决定的.
要么是需求旺盛,顺理成章地提高价格.
要么是对于卖方来说,低价多销并不优于高价滞销.

对于前者,基本上是无解的问题.
如之前所说,只要不到上限,就可以一直攀升.

而后者,则可以考虑的东西比较多.

降价反而降低收益,也就意味着由低价造成的销售额上涨弥补不了损失.
换句话说,就是买方的购买能力并没有因为价格的降低而成比例地增长.
也就是购买力或者说收入水平所限制.

则解决方法只能是寄托于经济水平的上升.

换个角度想的话,如果削弱高价带来的利润空间,那么均衡点就可以向低价靠拢,由量弥补利润差.

一个可能的方案就是让卖方的持有成本跟数量成正比.

但是如果只是政策性地通过税收之类的手段跟空置率挂勾,那么最终也会发生成本转嫁.
毕竟,从严格意义上来说,这并不构成必要成本.

也就是说,凡是通过增加持有成本的手段,最终都有可能转移到买方身上.
这样似乎又无解了.

但如果比较系统地看待利润这个问题的话,就可能不一样了.
毕竟所谓利润不是一两次词的交易构成的.

考虑到房地产行业的特性,如果没有足够的资本供运转的话,就可能会产生风险.
而如果在融资渠道受限的话,那么就只有依靠自身的快速收回成本来完成.
这也就有可能变相地增加持有成本.
因为持有地越久,周转周期就越长,结合考虑周期的收益率的话,那么在计算真实收益率的时候就有两个因素考虑了.

也就是说,即使周期收益率变低,但是如果周期同时变短的话,降低价格也是有利可图的.

因此,这个解决方案的关键点在于银行借贷的控制和其他融资手段的约束.

当然,现实情况可能更复杂些.
因为它确实可能是某种程度上的需求旺盛.
比如购买固定资产作为投资保值手段.

只要房价的涨幅大于年利率加上贷款利率的话,一般就认为是有利可图的.
在某些全款投资的情况下,只要大于年利率即可.

这个还是相当容易达到的.

所以,提高首付比率某种程度上来说可以减少一些小额的投资参与度.
而房产税和利率调整也可以相当程度地组织资本进入.

然而,这毕竟只能稍微降温而已.
并不意味着不能反弹.

因为在这些政策前的资本收益率是基本不受影响的.
也就是说,只要不出现价格负增长,那么他们的利润是有保障的.
也就是会到前面所说的,降价出售并不会给他们带来额外利润.
因此,他们的成交价格必然会高于一定水平.
同时成交量的多少决定新水平的高度.

也就是说,只要还有这部分前期投资在,那房价就不太可能会负增长.

而由于是固定资产投资,拥有非常良好的抗通胀能力和收益率,所以很难会被置换成其他投资产品.
尤其在当前环境下,基本没有安全系数类似的替代产品,或者其他更高收益率的风险产品存在.

所以,如果没有其他投资渠道的话,即时能够暂时抑制新资金的流入,但是老资本依然无法消化,最终只能反弹.

所以,某种程度上来说,房价是地区发展不平衡,加上贫富差距造成的.
尤其后者可能更具有影响力.
因为即使地区人口均衡了,也避免不了投资行为产生的负面影响.

所谓价值

看完 证券分析.

一个感想就是,证券市场是怎样的取决与里面参与的人是怎样的.
因为这是一个纯粹的参与者之间的零和博弈.

尽管里面交易的是证券,而证券背后有各种各样的协议支持.
但在市场上,它的价值在于提供获利基础.

某种程度上来说,金融市场是个很可怕的地方.
它能够将所有东西变成可获利的.

就像公司债券本身只是一种融资手段,金融市场使得它具有相当的流通性.
而这种流通性本身提供了买卖可能.
从另一个角度来说,买卖的发生就意味着差价的存在.

有差价就有利润.

所以,即使是最理智的市场,使得债券价格不会超过其固有差价的上限,那么理论上也是存在资金从一方完全流向另一方的可能性的.
更不用说面对以市盈率等所谓未来价值评估的股票市场.

股值本身就以及偏差了股票原有的价值,而流动性更会加剧这种偏差的扩大.
因为只要有公司价值扩大/盈利的可能性存在,那么就近乎必然地将拉高市场价格.
而尽管,此时的价格早已经不代表当前资产表现了.

但偏偏问题就在于,这种偏离看上去又是非常合理的.
因为在给定的未来时间段,如果公司利润保持在一定水平,那么折现的话,也确实能令人信服.

这就显得微妙了.
因为本质上,大家面对的都是各自计算出来的一个估值.
它跟公司现状有关,但没有必然地关系.
因此,从某种程度上来说,价格的波动在于是不是有足够令人信服的计算来反证其合理性.

看上去就是"因为它要涨/跌所以它要涨/跌"的互为因果的诡异境地.
它取决于有多少人信并跟近.

所以,在一个多数人都"理智"地遵循一些模型的时候,那么这个市场就似乎是科学的,因为能够被相应的理论说描述预测和解释.

于是,一个市场的正确观察方式取决于市场中多数人对某一刺激的同一反应.
而反过来,因为市场对某一刺激会做出某一反应,于是人们也慢慢会趋向同一条件反射.

这样看的话,难免会让人有些哭笑不得.
因为从某种程度上来说,一个市场的风格形成跟任何经济条件金融理论都无关,而只受第一批参与者的思维方式约束.

当然,这只是一个方面,或者说主多方法论之一.

就像该书所定义的投机行为一样,只是以市场反应作为价值衡量手段的一种方式而已.
也就是说,存在着其他的价值衡量方式.
比如回归债券本身.

从根本上来说,这些只是着眼点不同而目标明确.
从中获利.

也就是说,只要有差价的存在,无论是发现还是创造,那么就有利润空间.

明白了这点之后,很多事情就豁然开朗了.

比如说所谓商业模式.
要么是能够创造价值产生差价.
要么就是能减少成本.

而很多时候,这两者也并没有区别.
因为人都是为价值买单.

没有给人带来价值,又如何能产生转移和利润呢.

剩下的,就是如何定义价值的简单问题了.

反向代沟

看新版笑傲江湖的某些弹幕,忽然觉得代沟这个问题其实是双向的.

前人固然可以去了解和接触后人的人生观世界观,并维持某种程度的同步.
但是前人本身的生活背景对于后人来说,却未必有大的价值,从而引发反向的同步.

这个造成的问题就是,你所认为应该是常识的东西,后者可能会觉得新鲜.
而尤其如果前人试图借助这些所谓常识去宣传一些东西的时候,可能就不会有相应的效果.
因为对于后者来说,缺少了对应的上下文.

就像一个人也许觉得仙剑是神作.
但是,对于新生的人来说,可能是很难接受的东西.

而且,这种感觉也往往是记忆所修正美化后的感受.
即使本来不如何,但是经过模糊化处理之后,可以产生时代性的共鸣.
但是,这种共鸣对于新人来说,是不可能存在的.
因为没有相应的背景经历.

也就是说,即使一个人能够完全地同步后代人的所有背景知识,但是在交流和沟通的时候,依然会存在代沟.
而且这种知识背景的差距基本上是不可俞越的.
因为沟通及理解是双向的.

尽管有些东西可能会再次流行从而在新老之间完成继承同步.
但是多数情况下,是不会有此幸运延续的.
能够所谓流芳百世的也只是一小部分.

而问题在于,一个人似乎并不能很确切地知道,到底哪一部分是对方所没有的.
因为对于前者而言,这些都是常识.

所谓常识,就是毫无怀疑的理所当然的前提条件.

这就有点有趣了.

也就是隐喻着,沟通始终是存在障碍的.

换个角度看的话,就是各代的文化总是会有其奇特性和差异的.
而有些微妙的是,这种差异可能并不是因为新生了什么东西.
反而是缺失了部分所造成的.

当然,事实上的差异更可能是同时由这新生和缺失构成的.
但是,这种缺失所造成的差异,似乎更为有趣.

因为缺失的部分并无所谓的优劣,而只是纯粹的空白所造成的.
也就是说,无论多好或者多坏的东西,都有可能成为这一部分.

换句话说,从整体上来说,无论多么优秀的东西,都可能会消失.
而且这种消失,并不见得是后代不接受.
而是前辈不"给予".

所谓反向代沟

Chrome扩展的碎碎念

假期长的一个好处就是,说不定很快就会闲的略感无趣想找些事情来做.
即使之前可能还想着终于可以休息了.

在家今天,心血来潮就想着写个chrome的代理扩展.

之前一直在用Proxy SwitchySharp.
想重新造轮子的原因也并不是不好用.
只是实在找不到什么事做.

另外一个原因是每次换个设备就要重新添加代理规则.
虽然也有现场的GFW list,但到底有多数其实是不用的.

于是,基于这个动机,开始便打算改改switchysharp,加个同步功能好了.

但是在看了相应代码之后,考虑到license是太喜欢GPL,于是只好放弃.
向上游的switchy plus看也是一样,GPL license.

只有原始的switchy是除GPL和MIT dual license的.
只是不知道具体什么情况是GPL,什么情况是MIT而已.

发邮件问作者,也没回复.
看来英文表达实在是太不堪入目了吧.

所以,只能重新开始.

不过要真是从switchy开始的话,改动还是挺大的.
毕竟历史原因,switchy时代chrome还没有原生的proxy只是,所以只能生成pac script然后通过对于OS的native 调用去修改系统代理设置.

看了下chrome的proxy api,其实也就三两行而已.

原则上来说,这几行就足够了.
手写一些pac然后save的local和storage里的话,就行了.

但浏览API的时候发觉似乎能够拦截浏览器请求,于是想,检测下RESET之类的,自动添加生成也省一些功夫.

于是,拦截了一些比较大几率是GFWed的失败请求,然后生成pac自动apply了.

到这里,本来也没什么事了.
但是忍不住想把能合并的规则,比如a.wordpress.com,b.wordpress.com之类的合并为*.wordpress.com.
于是这几天的事情就是调试这个.

结合自己几天的使用下来遇到的一些edge case,只尝试合并了二级域名以上的.
不然,像a.org,b.org之类的很容易合并为*.org,最后就变*了.

另外一点就是最初其实考虑到storage的大小限制,所以在记录失败网站的时候加入了计数器.
原始思路是想如果超出storage限制的话,自动抛弃计数小的.
毕竟,数值小代表访问频率低.

但最后还是没把这个限制检测加进去.
因为实际看了下自己的使用情况,实际条数也不多.
而且真到有必要的时候,大概也比较容易吧.

遇到的一些问题,比如偶尔浏览器会卡住一段时间的现象.
如果不是最近chrome版本自身问题的话,那就应该是并发访问一些数据结构造成的race问题吧.

也懒得去验证了.
简单地用alarms做延时修改和合并.

因为文档上指alarms的触发时间只是大约的限制,并不严格.
而且开发时候也没遇到特别严重的延时,大致能接受.

但是放到chrome store上之后,似乎就延时比较严重了.
推测是开发时候的调度优先级高一些吧.
于是只好最终去掉.

反正调度有延时,那竞争情况也顺应地会少些吧.

于是最终产品就是类似这样的.
http://goo.gl/HMZ5H
然后简单地写了个配置页面方便添加代理服务器.

至于实际使用起来,还是有些不太友好的地方.
如果网页是被RESET,那自然很好,刷新一下就可以了.
但是如果是一些干扰性的,比如DNS污染或者干脆连接干扰,造成页面长时间加载不出来的话,只能等最终timeout再刷新了.

有想过想switchy系一样支持手工加入规则.
后来想想还是算了.
毕竟涉及用户交互,要容错的地方比较多.
行数应该少不了.

另外一点就是,看API的时候看到似乎能够直接修改请求结果.
这样的话,理论上,加个background page,然后把goagent之类的用javascript实现一遍也是可以的.
或者直接透明修改请求应该也可.

最后一点是关于这个窥探请求带来的一些风险问题.
毕竟所有请求内容都是可见的.
如果用来做些其他什么事情,加上用户可能不太关注的话,很容易出问题.

所谓技术的中立性嘛,协议或者API什么的本身并没有好坏之分.
关键在于用的人.

尽管,设计的开始就应该考虑到这类API可能被滥用带来的问题.
但是,凡是考虑也都会有疏忽的地方,免不了一些看似常规的手段滥用.

就像TCP至于GFW.
技术角度看,完全是合理而且优雅的.

Don`t be evil.

纯粹商业逻辑

断断续续看完 美国宪法评注.

一个感想就是,经济基础决定上层建筑 这句话也不是没有道理.

独立战争前,美国各个州不过是各殖民公司的属地.
相互是独立平等的.

而这点也是为什么后来为什么会以联邦形式存在的理由.
因为本来就只是为了共同抵御帝国的反扑而建立的贸易联盟性质的团体,因此也就没有超越各州存在的一个中央权力.

独立战争在某种程度上是一种贸易权利/商业利益的抗争.

尽管各殖民公司在殖民地的运作和裁决几乎是独立于帝国的,但是由于帝国要求各公司必须注册在本土.
因此,实际上是受制于与英帝国管辖的.

而从根本的点上来说,殖民公司本来就是帝国贸易的一种方式.
只不过通过税收的方式换取实际的贸易利益.

所以,从殖民公司的角度来说,是以税收换取自治权.

在收入还足以抵抗税收的时候,这种帝国殖民方式并没有什么大的问题.
但是,一旦税收造成的经济负担到达某种临界点的时候,就有可能引起殖民公司的不满.
这也就是独立战争的契机.

所以,从这个程度来说,联邦的建立不过是因为各个殖民公司有着需要共同解决的问题,同时因为属于不同的殖民公司,又不存在一个足以兼并其他公司的巨型存在,才有不得已而为之的一个折中结果.

这也就注定联邦政府只能作为一个协调人的角色存在,而不能直接干涉各州自己的内务.
只有在涉及州间事务,或者由独立州执行将带来贸易问题的时候,才会交由联邦解决管理.

这使得联邦很难成为由一个中央权力代表的集团.

当然,也不能说它就是完全平等的或者说完美的.
就像饱受争议的选举人票制度.
它还是存在一些不"公平"的地方,使得一些州"优于"另一些州.

但总体上来说,由于存在的实力差不多的"州",所以,大致上还是受到均衡约束的.
也就是说,还存在着需要"多数原则"的地方.

而正因为没有"兼并"的可能,才是的各个联邦级别的"部门"只能充当经理人的角色,而不是全权的管理者.

所以,某种程度上来说,是贸易的对等性早就的联邦的体制公平性.

换个角度,如果存在一个能够兼并其他殖民公司并最终对抗英帝国的实体的话,那么也就大概不会有联邦政府了吧.
比如中国历史上的各种割据时期.
最后还是成王败寇的大统一局面.

稍有相似的就是对日抗战的国共合作时期,算是均衡势力的互相妥协与共同利益的折中.
只是后来力量对比产生差异,失去了类似的谈判条件.

而且,某种程度上来说,国民政府是受累于自己的正式国际地位.
毕竟就当时来说,红军并不算是一个得到承认的实体政权.

所以,攘外必先安内 算是一个合理的思考.
只是,实在是内忧外患,不得不妥协吧.

回过头来,初期的美国宪法其实挺多是源自英国法的.
或者说,其实世界上有不少地方的法律是源自英国法.

毕竟,殖民时代算是第一次把世界文明相互联系起来了.
殖民地自然不可避免地会受到母国的影响.

另外一点比较有趣的是,英国管理殖民公司的方式.
似乎算是某种程度上的骑士役的变种.
给予占有土地的权利,作为交换需要为帝国服务.

作为一个兵力有限无法直接占领庞大领土的国家来说,权利交换算是一个很巧妙的方法.

不过这么看的话,其实多数问题都可以归结为利益置换的问题.

以物换物.
纯粹商业逻辑.