看到今年的诺奖经济学奖，不禁想矫情的回顾一段岁月。（非常矫情）
大三寒假那段格外失意的日子，翻开了拉丰的《激励理论》，从此迈入了Toulouse系基于信息经济学的宏大的委托代理框架。那个时候没有人开这门课，就一个人跑到图书馆里面借来这本书，然后采用最笨的方法：一页一页的抄。不仅仅是抄文字公式，连图都没有放过，一张张认真的临摹下来。这样的日子大概过了两三个月，终于抄完了这本书，其中还是懵懵懂懂的很多。然后决意写论文，就有了第一篇关于声誉制度的讨论的论文。边写边看，对激励理论的理解也就越发的深刻。后面再看Toulouse系的其他书，大都也是这个框架，只是具体问题的差异了。
时隔整整五年后的今天，再回忆那段日子，倒是觉得各种美妙的滋味难以言喻。那是每个“躲进小楼成一统，管他春夏与秋冬”的孤独的前行者都会体味到的美妙之处吧。时至今日，激励理论依旧是我分析问题很重要的一个角度，用博弈的角度看问题，有时候真是风景不同。
听，那年的风声依旧作作呢。
今儿听Hadley大人做training，才第一次好好去看pipe这个东西...以前有点印象，主要是R会上有人讲过，当时只是记住了一个名词。今儿才有机会好好的去看看去想一想。（吐槽：R有的时候是不是太灵活了...）
pipe的广告语： the pipe operator is one (if not THE) most important innovation introduced, this year, to the R ecosystem. 听起来挺神奇的，好像是从F#那里搬过来的....R果然是耐揉。
短短的历史就是，随着Hadley大人搞定了dplyr，MAGRITTR 这个包开始浮出水面，各种热门...
然后果然COS上有人介绍过，Ren Kun童鞋早已经进一步弄好了一个pipeR包可以玩：http://cos.name/2014/04/use-pipeline-operators-in-r/
然后再去看今年5月份北京R会议的slides...原来这么赞（可是当时我明明在北京呀，当时干嘛去了...总是这么后知后觉）。
然后COS论坛上果然早早就有讨论了，这群geek...
没了，我要好好学习去了，R永远是个学不完的东西啊啊啊啊！三观总是不时被重新颠覆一次，唉。
好久没写科普类文章了。今天想起来以前经历过的一个经典故事，不妨写出来记录一下。挺好玩的。
先列几个关键字：细分市场、价格垄断、坐市商
故事要从大概两三年前讲起。我一直有泡坛子的习惯，这个坛子便指论坛。一般来说，某个细分领域专业的信息肯定是论坛里面的，而不是随便网上搜搜就那么容易搜到的。每一次想进入一个新的领域，我一般都会开始看找个专业论坛泡着，大概泡上个一两个月也差不多把这个领域摸熟了，然后视情况而定是不是继续泡着还是可以走了。
以前经常泡的一个坛子就是一个常旅客论坛。现在这个坛子名气大了，但凡玩常旅客或者甚至跟常旅客无关、只是偶尔有旅游需求的童鞋们和一些信用卡羊毛党都喜欢去那里转转。几年前的时候那个坛子还没有这么多人，所以大家是一个相对封闭的小群体（有段时间论坛只能邀请注册，且大部分帖子都不是对外公开的，需要一定级别才能看到）。论坛里面自然你来我往七嘴八舌讨论的都是一些关于常旅客计划（飞机+酒店）的事情。
但凡人多了，便有了交易的需求。比如帮忙用内部价格定个酒店房间啊，航空里程出售交换啊等等。这里面最让我印象深刻的是，那段时间某酒店集团对其最高级的会员实行邀请函制度，即如果你成为了那1%的最高级会员，便可以有一次机会邀请你的朋友也成为这样的最高等级会员。成为最高等级会员的好处不言而喻：房间升级啊、专人服务啊、免费畅饮mini bar、免费使用行政酒廊啊等等，与此同时大概也是玩这个圈子里面的人一种身份的象征？
由于好处众多，所以开始设计的针对“亲友”的邀请函制度渐渐的变味了，成为了可以私下交易的“高级会员资格证”。一开始的时候，还仅限于论坛一些自身的玩友圈子里，毕竟邀请函的价格也不是那么便宜——当时的市价大概是两三千块钱，可能稍稍有波动，但是离不开这个范围。有些人不喜欢这个酒店集团，或者有些人没那么多的差旅需求，自然不会去购买这样的邀请函。而且一开始拥有邀请函的也只是论坛里面极少数的常旅客达人，所以这个供给和需求都是相对不多的。此外，由于酒店集团本身严厉禁止邀请函的“变现”行为，所以大家也不是特别声张的在做这种地下交易，一般还都是集中在少数几个熟人圈子里面，免得给自己惹麻烦。
当时论坛有位大佬，这里称之为A哥。A哥在那个酒店集团板块混得风生水起，基本上大家都蛮信服他的。在邀请函有交易的那段日子，基本上大家出价或询价的时候都会问一下A哥。若是有人想出的价格比A哥给出的“公允价”高，那么显然他是卖不出去的——A哥手里有多份邀请函的备货（有点垄断的货源，但不是A哥本身卖），一般购买的也就是那么几个人，分分钟把试图卖价更高的无知份子秒杀。如果有人急于出手，比公允价低，那么A哥他们就可以顺势收买过来。
就这样，A哥成为了实质上的“坐市商”，即拥有了这个极为特殊的细分市场的定价权及大部分话语权。有意思的是，A哥本身并没有实质的货源（最终还是需要推荐人来操作），而他凭借的只是多年来在这个市场上积累的信誉和人气，便足以垄断价格。于是该邀请函的价格在接下来的一年多的时间内一直都稳定在两三千块钱。
然后大家都知道的，坛子里最不少见的就是变化，尤以这种极度和职业相关的坛子。大概经过了两三年的光景，慢慢的坛子里面的“老人”就淡出了，新人们慢慢的涌入，论坛的风气慢慢的就变化了（明显的就是年轻的或者爱炫耀的土豪们增多，什么“学生党头等舱穷游世界”，只能呵呵了）。中间经历了多少波折起伏我也不甚清楚，反正我自己是不怎么泡了。前段时间搜一个东西搜到了，就顺便去坛子里面逛了一圈（帐号权限什么的倒是还都在），发现现在同样的邀请函交易还是存在，但A哥们已经不在了。随之而来的就是价格已经一路飙升到四五千，其中还不乏有人囤货居奇、各种炒作什么的。当然市场的变化总是正常的，只是市场的氛围也就乱掉了，不时有人抱怨诈骗啊、不守信用啊什么什么的。反正在这种地下市场中大家都是有点赌运气的成分，单品的价格也不算低，有的时候相互之间的谩骂什么也就在所难免了。我自己而言，还是喜欢以前那个相对明码的市场，至少是有秩序的嘛。现在乱成一团其实挺讨厌的。
想说的只是，有的时候见证一个细分市场的发育过程，还是一件蛮有意思的事情。从一开始的口口相传的信用，到后面越来越多“官方”味道的各种制度的介入，到最后稳定在一个新的市场均衡形态，不知道下一步的市场会如何蓬勃发展还是慢慢消弭。这远比看那些已经非常成熟的市场来的有意思。
不是说学一门语言学的不仅仅是他的语法，更重要的是他背后的思想么？R本身是个大杂烩，ggplot可以单独拎出来作为一门语言学，shiny其实也可以单独拎出来学一番。
只是简单的实现一个shiny app确实不难，就像官网上一进去看到的那个例子那样。基本上如果只是做一些比较简单的可控的dashboard，shiny的代码无非就是写的细致一点，谈不上什么架构之类的。
直到某一天...你发现这东西还可以玩的更深，然后就毅然跳入了下一个大坑——shiny reactivity。官网的开场白很直接：
It’s easy to build interactive applications with Shiny, but to get the most out of it, you’ll need to understand the reactive programming model used by Shiny.
然后就介绍三剑客：reactive sources, reactive conductors, and reactive endpoints。
继续拷贝官网图：
嗯，听起来不难...其实大部分情况下shiny app处理的都是这样的情况。基本上就是一个输入（input）和输出（output）的过程。最简单的，就是我们经常在shiny app里面需要处理的input对象，会读入各种用户操作带来的值，然后后面返回一个表格或者图或者文字什么的。回到官网的例子（继续拷贝官网图）
shinyServer(function(input, output) {
output$distPlot <- renderPlot({
hist(rnorm(input$obs))
})
})
大概就是这么一个简单的架构。在这种架构下，自然可以写很多if else之类的在server.R中加入各种各样输入输出的组合，然后在ui.R中排列一下输入的各种框框和输出的各种图标文字什么的。
shiny用的稍稍熟悉了，就开始想更多的控制这个东西。其实conductor说白了有点中间变量的感觉，就是他本身并不会最终显示出来，但是作为一个中间过程存在着。比如官网一个计算Fibonacci 序列的例子：
fib <- function(n) ifelse(n<3, 1, fib(n-1)+fib(n-2))
shinyServer(function(input, output) {
currentFib <- reactive({ fib(as.numeric(input$n)) })
output$nthValue <- renderText({ currentFib() })
output$nthValueInv <- renderText({ 1 / currentFib() })
})
这里无非就是多了一个新的对象currentFib（跟input和output都无关），暂时的存储了一下计算过程中的变量，然后基于这个东西，又衍生了两个最终显示出来的返回值。新的架构图就多了一个conductor这样。
按照官网的说法，这个东西包括：
基本就是从其他的数据源而不是用户的input那里读数据的情况。常见的场景比如，按照用户给定的一些条件(由input传入），返回一个符合条件的数据子集。如果数据全集是会不断更新的（比如每次都应该重新load("xxx.rdata")这样），那么这个这句话就必须写在reactive里面。同理，如果直接利用input生成一句SQL然后连接数据库读取数据，那么也要写在reactive里面。
shiny默认的情况下，如果没有放submit按钮，那么就是随便一个操作就trigger整个reactive的流程。比如官网首页上，我们拖拖鼠标那个直方图就跟着变化。如果不想让他直接变化，那么简单的可以放一个submit按钮，然后只有submit之后才会变化。
如果希望更好的控制一个app界面上各个部分呢？就要动用更高级一点的actionButton。
这东西还要配合一个isolate()，就是你要告诉shiny哪些东西跟着这个button变化，哪些不属于这个button的控制范围。比如官网的例子：
shinyServer(function(input, output) {
output$distPlot <- renderPlot({
# Take a dependency on input$goButton
input$goButton
# Use isolate() to avoid dependency on input$obs
dist <- isolate(rnorm(input$obs))
hist(dist)
})
})
这里只有goButton被点击的时候，才会执行下面的抽随机数并画图。actionButton是随着每次点击而不断增加计数的，从0开始一直增加过去，所以可以在server.R里面利用这个button的返回值来进行流程控制。
篇外废话：
shiny有希望成长成一个可以替代php这样实现客户端和服务器端大部分交互请求的巨人么？从这点来看，Tableau还是限制太多了。
只是存一些代码。