Fengxiaoping's bubble

(30 hackdays day 8) Physical web – 给鞋子一个网址

10月 17th, 2014
本来今天是想写Google Alerts的API的。结果发现之前的API的repo不能用了。悻悻然，就再找一个吧～

因为一直在关注iBeacon，所以前段时间看到Google的Chrome团队出了个Physical-Web项目，一下就亮了。

让你的鞋子有个URL

听起来很酷，让每个东西都有自己的URL，很典型的Google式思维。具体做法也跟iBeacon很像，只不过把广播帧里传输UUID/Major/Minor变成了直接传URL。我暂时把这种Beacon技术叫做webBeacon。做过iBeacon开发的人都看得出这里一个很大的好处，就是省去了一步翻译过程，可以更容易的做cache了。下面就是它的广播帧。
```
uint8_t advdata[] =
{
  0x03,  // length
  0x03,  // Param: Service List
  0xD8, 0xFE,  // URI Beacon ID
  0x0A,  // length
  0x16,  // Service Data
  0xD8, 0xFE, // URI Beacon ID
  0x00,  // flags
  0x20,  // power
  0x00,  // http://www.
  0x41,  // 'A'
  0x42,  // 'B'
  0x43,  // 'C'
  0x07,  // .".com"
};
```
实话说前面的部分没太理解，多了解下BLE再看。后面的部分自然就是发射功率和URL了。发射功率是用来做RSSI定位的。URL部分看来是不打算支持unicode的哈，还给.com专门搞了个数字7（你让Bell情何以堪…再Terminal里按control+G就能碰到它）。

话说突然想到入珠这个话题…然后就突然想到支持Physical-Web的入珠。然后就脑补出一个颠颠的走在路上的家伙，丁丁不断Broadcast一个广播，是一个网址。然后旁边的人掏出手，机（总觉的这句话在这个情景下好奇怪），看到一个丁丁的网站…

Coder的BLE – RFduino

借由文章的介绍，我了解到了还有可以让小破Coder也能轻松开发BLE底层的工具RFduino。因为那帮Googler觉得市场上现有的beacon不方便改广播帧，所以推荐了RFduino，还在Repo里专门放了个用于RFduino的firmware和一个用于发现这种广播的Android程序。进去以后发现不光是RFduino可以做成一个webBeacon，Android，Arduino，甚至nodejs都可以…模拟成一个webBeacon了！因为Android的要求系统最低时Android L，所以我只能试试nodejs版本的了。好吧，最后它告诉我Mac不支持，只支持linux。那..看来最可能的就是我把Nexus5升级到Android L。

Android端接收程序

所以呢…这么短的博客不好吧…

OpenBeacon

我只能硬着头皮往后看。发现了个OpenBeacon这样一个发射端实现。进去网页发现这是个2006年开始的开源项目。当初是做开源的2.4G RFID，后来加入了BLE。

里面的一个视频是他们的愿景：线下人们之间的接触行为＋线上结构化语义数据＋线上SNS的数据＝实时的整合社交图谱。视频里它给出了一个实验室案例。真的很酷！但…它勾起了我当年做网络仿真时不好的回忆…也罢也罢…

看了那实时的效果是不是瞬间觉得Person of Interests里的世界似乎已经发生了呢～

好啦好啦，终于感觉不那么愧疚了！睡觉！
(30 hackdays day 7) Iron.io + beantalk 来颗铁豆

10月 16th, 2014
前面说到我打算用PubNub实现爬虫模块之间通信，但PubNub有一个比较麻烦的问题就是不能像MessageQueue那样实现异步消息传递。虽然PubNub也提供history()这样的函数可以封装为MQ的样子，但始终是有点文不对题的意思。
所以我决定再找一个MessageQueue的服务来做这事儿。以前我用过RabbitMQ，但那个毕竟要自己搭建服务。所以决定尝试一下另一个MessageQueue的Service Provider

Iron.io

Iron.io提供一系列用于Scale的服务，IronMQ (message queue)，IronWorker (其实这才是重头戏), IronCache (呃就是cache)。
这次我们只用message queue。Iron.io使用的是自家的IronMQ，2011年得到过$1.1M Citrix的投资。Iron.io做了一个compare table来跟其他MQ做比较。主要的优势体现在scalability上，就是各种能轻易扩大规模，换句话说，就是等你做大了只要多交钱就好啦～

Naked Message Queue

用过RabbitMQ的人都应该对它SDK封装的程度印象深刻（简单说就是超好用）。而IronMQ的特点就是…赤裸裸…至少Nodejs的SDK是这样。 node SDK提供的接口里最让人不爽的就是Retrieve message的部分。一次只能get一条消息，然后一旦没有消息就得到一个empty message的callback。虽然get可以设置一个wait，让它不立刻返回。但wait最多也就等30秒。所以如果要做一个简单的Daemon来接受消息就还要做一些循环封装（弄点儿Timeout啥的）。
作为一个这么懒的人，这咋行呢！按以往的习惯，这时候应该已经开始寻找替代品了。但…我交了5刀…所以…

Beanstalk Interface

为了5刀，一条条翻看Document，突然发现了个好玩的东西：Beanstalk Interface。稍微一搜发现这玩意儿正是我要的！（有没有想起JavaBean…）
```
Beanstalk is a simple, fast work queue.
```
Beanstalk是个抽象设计，所以有各种语言的实现。一一翻看Nodejs部分的Client。
NPM里的repo可以看到每天的下载量，这就给开发者一个很好的选择标准。我的标准是这样 NPM downloads > Github watch > Github fork > Github last update time。fivebeans和nodestalker，最后决定用后者，因为更新时间比较近。

Watchman

测试了一下nodestalker的watch以后，发现似乎它的实现是同步的，会导致整个node项目无法处理新的request。而nodejs默认来说每个Process就一个thread，所以如果要在一个项目里同时监控message以及随时可以发送message的话，就得单起一个Process。worker.js是我的一个用来放watch process的文件。
```
var childProcess = require("child_process");
this._retrieveChild = childProcess.fork("worker.js");
```
Iron.io的服务需要认证，而认证的方式似乎比较奇怪：连上Queue以后先发一个Message，里面包含认证信息。
```
var authJob = client.put('oauth ' + MQ_TOEN + ' ' + MQ_PROJECT_ID);
```
在这个Job完成以后就可以做事儿啦～

抱怨

因为nodestalker用的是大名鼎鼎的mikeal的request。而因为受到AVOS的熏陶，写点儿啥都想用Promise。但…丫就是不支持！还看到一个牛逼哄哄的回复

你丫就得搭金字塔，你丫就得…哎…所以我就搜Promise Request mikeal。发现一坨坨的…Promisify大有“互联网思维”的范儿。

Sample Source code
(30 hackdays day 6) UserApp – 管管那帮用户

10月 15th, 2014
框架可以提供给你很多方便的特性，但也会剥夺你的自由。活的久的框架都不做太多“实事儿”。

用户管理这事儿很麻烦。原来只有User/Password，后来发现要加密，再后来出来了OAuth。如果现在你要做一个产品，还在纠结怎么做用户管理比较方便，有扩展性。UserApp会是你喜欢的。

作为一个管理用户的服务，最重要的，当然是开心。最好是能帮我把用户各种登录，连界面一起写好～嗯嗯，最好还能按我的需求来选择前端和后端的技术；还有还有，最好要加上付费，听说那个很麻烦；当然，标准价，套餐价什么的要是能加上就太好了。

好吧，我是在说一只咸鱼的理想。

一只咸鱼的理想

是的，又是Get Started，你们丫以前是不是专门做登录的…这里你可以选择前端后端的技术，比如我选择Front-End为Angularjs，后端为Nodejs，然后它就会给你生成一个具有登录，还有脸！的Angularjs程序框架，连partials都准备好了。然后后端就会生成一个带Passport的Nodejs工程（作为Passport的一个Strategy），npm install一下就能跑了。
最后，在Congratulations的页面还告诉你，你的账号系统可以一键跟MailChimp同步！打开More发现还有mixpanel这个静静的美男子，以及stripe这货。

为啥要咸鱼

“\w+类资料还是放在我们自己的服务器上比较好”，一定match了很多你lead的话吧。用户登录凭证保存在自己服务器里的唯一好处就是，在天朝里访问速度可能快那么一点点。而坏处呢，配HTTPS，容易被爆库，自己做SSO，自己关联所有其他服务的UserID…it’s ok, fine.

ACL matters

问题又来啦，一个用户管理系统对严肃的系统最大的影响是什么？权限控制。当然ACL可以适用于基本所有普通系统。UserApp提供了许多服务（对于UserApp这些也是它的库），以至于调用起来时这样的（我爱JS）：
```
UserApp.[service].[method](arguments, callback);
```
哦，跑题了。ACL，最重要的呢，也是开心。Dev看ACL就两条：这SB用户有啥权限，这SB用户有没有这SB权限。
```
user.get(); user.hasPermission() 
```
OAuth painless

UserApp内置支持Google Github Facebook Linkedin，这些OAuth所需的配置都在UserApp的Dashboard里就能完成，点点就好。但是，但是…我没找到在哪里添加自定义的OAuth的说明。看来如果想在中国用只能自己写了..
好吧好吧，我知道你失望了，我发个mail问问他们…

最后，这又是一个付费服务。不过，是按用户量来算的。所以如果你的应用一直维持在几十几百上千的量级，基本就不用交钱哈。
总结呢，还是用AVOS吧…
(30 hackdays day 5) Page2Images – 特别肤浅的收费服务

10月 14th, 2014
上一篇讲到爬虫，爬取页面里的文字内容是最基础的，除此之外我还想要整个网页的截图怎么办呢。Page2Images就可以上场啦。在Leanstack上，这类服务被称为Screenshot as a Service（又一个SaaS…）。这么看来Service as a Service不远了啊（是说就是consultant么，那有没有consultant的consultant service呢）。

作为一个肤浅的服务，最重要的就是…脸。相比它的同行URL2PNG，Page2Images的小章鱼和Github有一拼，所以，好了就它了。突然想到，要是有个服务让我一输入名字就显示出Ta的脸，该是有多…肤浅。于是我搜了下“冯小平”，找到了第一张单脸照。

好，等我出名以后再找这种服务…

为啥Images是复数

从名字Page2Images可以看出，他们的数据库试图设计成一对多的关系。因为，“男人不止一面”。一个页面也可以有很多Screenshot，尤其是在这个Responsive肆虐的世界。好，你想到了Phone，Pad，Desktop不同尺寸是不是？嗯，直接来看最简单的使用方法：在你的页面插入一个标签，里面显示某个网页的某个尺寸的截图。章鱼给了个简单易用的工具来帮助你生成想要尺寸的截图。出来的HTML差不多长这样。
```
<img id="”p2i_demo”" src="//apple.com&amp;p2i_device=4&amp;p2i_screen=768×1024&amp;p2i_key=b00cc2e6ac5e8f**″" />
```
好了我知道你想说：我这里现实的没有框啊！嗯，自己找参数去。

好了我知道你又想说什么，为啥目标URL不encode啊！呃，其实吧，不encode又怎么着…嗯，除非你蛋疼的爬到一个URL
```
http://service.exmail.qq.com/cgi-bin/help?u=0&amp;p2i_device=6&amp;id=28
```
懂了吗？没懂去锻炼锻炼。

Direct Linking API KEY & Rest API KEY

这类服务为了收钱，一定得把收费的部分做到比较严谨。所以Page2Images里把API key分成两类，Direct Link和Rest API。前者用于在前端页面使用，比如img，javascript，后者用于服务端调用。所以前者除了要验证Token以外，还要被绑定在某个Domain或上，而后者只要带着对的Token就能访问。（所以如果有一个建站工具里，a.xxx.com是一个站，如果创建Direct Link Key的时候没有注意，Domain写了*.xxx.com，则b.xxx.com也能用前者的Token了）。

为毛比URL2PNG贵

URL2PNG不提供免费账户，但Page2Images提供，为毛呢？Price Table里有一个很重要的参数：Hits(Cached)，然后每天Unique URLs是100个。懂了吧，最大负担就是每个账号每天100个请求了。

最后感慨一下，人家做这么个都能收费。哎…
(30 hackdays day 4) PubNub – Connect everything in REALTIME way

10月 13th, 2014
上周末，我和刘宇波去上海参加了一个”Hackathon”，中日黑客马拉松，在做完Demo以后就直接走了。第四天啦，这次跟工作相关啦。

目的

我想做个简单好玩的爬虫，可以爬Web，以后可以扩展到Sensor，App，QS设备之类的各种数据源。

限制
- 支持pull，push两种数据抓取方式
- 爬虫运行环境higher than VPS
过程

第一个蹦到脑子里的词儿就是Cloud crawler。Google了一下发现又多出好多类似的服务，以前知道的有80legs和scrapinghub，这次找到了Parsehub，Grepsr，Diffbot。还有这样明确的外包做这个的人工服务crawley-cloud。

首先，我想尽量少写正则（写吐了），其次，我不想买个VPS干这事儿，然后，我想以后可以有更多数据源接入的时候，可以尽量减少对现有结构的干扰，最后，要实现够快！

第一步，设计一个大概系统结构。

爬虫部分设计成了一个被动调动的API列表，每个API对应一个数据源的获取接口。API由一个统一的Controller来调用。每次API调用都被赋予一个Task，用来记录爬取任务的结果。

所有的爬取结果都会被保存到Log里。由Filter对每一条数据进行净化处理。通过了Filter的数据被保存在Item里。

Worker用来对Item里的数据进行统计计算，结果保存在Data里。Worker也是由Controller控制触法的。最后用两个WebApp来展示Data和一个用来展示中间数据的Dashboard。

这次的点PubNub

可以看出前面这种架构的结果就是，分布在不同项目里，有好多Server在互相弱耦合的运行着。那他们之间怎么通信呢？PubNub就出场啦～通常我们会想到RabbitMQ这样的Message Queue类服务，但PubNub的胃口比这个大的多。从他的Slogan就能看出来：”Build and Scale Realtime Apps for Connected Devices.”，他们想做物联网的普世消息服务。仔细看看他们支持的平台，有点吓人…从Codenameone到PIC32…也就是说理论上，基于PubNub可以很容易写出一个用js写的native应用来通知一颗芯片点亮某个腿对应的灯泡。

还是说回这个项目。PubNub可以轻易实现pub-sub形的通信。Controller和Crawler安装上pubnub，使用key初始化好，就可以向某个channel发消息啦。下面是它的栗子。
```
var message = { "some" : "data" };

pubnub.publish({
  channel : 'my_channel',
  message : message,
  callback : function(e) { console.log( "SUCCESS!", e ); },
  error : function(e) { console.log( "FAILED! RETRY PUBLISH!", e ); }
});
```
超直观吧！Subscription也很简单。
```
pubnub.subscribe({
  channel : "my_channel",
  callback : function(message) {
  console.log( " &gt; ", message );
  }
});
```
所以当我看到PubSub的时候就感觉到传说中霸气的”Javascript on Everything”的时代，终于要到来了！

比起Firebase，PubSub更偏向一个Message Queue的角色，很直观的在传输消息，而前者更“数据库”一些，在设计的过程中需要仔细考虑如何将数据的变化作为通信的触发条件。

PubNub另一个特色就是它提供了大量的案例，而且不断在增加。而且这些案例里大量的都是物联网相关的，至少这些Case对我来说大部分都还是挺新挺好玩的。最后，爬虫的代码以后再公开～最后的最后，看到下面这张图脑子中又出现了三个字“买买买”…
参加过最烂的Hackathon

10月 12th, 2014
iHackathon.org，一个自费飞去上海，自费住宿的，我参加过最烂的Hackathon。
- 提前几周就报名了，提交的申请没有任何回复，都不知道通过了没有。
- 没有确定主题。号称为了避免提前做好了再过去参赛，要周五晚上才公布，结果也没有。
- 后勤很差，场地居然不提供插线板，提供的网络连Airplay都不支持。
- 主持人是路边捡来的吗。
- 比赛过程中一个话唠大叔…不想回忆的都…还让一个小孩在屋里来回拍球，跑来跑去。
- 所谓的中日，就是两边都在hackathon，然后中间通话，两个主持人聊聊天。
- 真的有拿着成品直接来拉投资的…
- 主办方有个大叔，跟人说话的时候好像所有人都欠他一样。
- 现场没有遇到一个有意思的聊天对象。
- 上海空气真好～
(30 hackdays day 3) Koding – 把chromebook变成开发利器

10月 12th, 2014
今天我要试试一款用来一起搅基Coding的产品Koding。现在尝试远程协作的团队越来越多，光靠Github来协同编码对于一些技术能力没那么强的团队是有些困难的。一来，Git的协作使用门槛还是比较高的，二来，这样的团队经常是3,1,1,1…这样的能力配置，也就是一个中等水平的工程师和多个初级水平的工程师。

这种配置就会经常出现一个问题：初级工程师经常要向中等水平工程师问一些初级问题。这种问题有几种询问方法（远程协作情况下）：粘贴代码发QQ，QQ桌面共享，先提交代码再clone到本地检查，电话。这些方法都非常低效a且无法异步工作。

另外呢另外呢…Chromebook是个很不错的笔记本，但要想在上面做开发，就得找个在线的IDE…所以…

Koding是一款在线开发平台，它提供全套的开发工具栈：VM/IDE/Termianl。跟Cloud9类似，Koding也提供终端用于执行各种命令，也就是在浏览器里就能执行Shell里那些命令，包括sudo。另外，Koding也支持大部分Web技术：Go, NodeJS, Ruby, Python, PHP, Java, C, C++, Javascript, Coffeescript。所以，一般开发一个Web产品，Koding就足够了。

Koding比较突出的特点就是它为每一个workspace创建了一个Docker虚拟机来运行，可以配置公共IP地址。并且这个虚拟机是跑在AWS的1G RAM，3G Storage，单核上的Ubuntu 14.04，性能对于一般的开发环境来说已经挺不错的了。

开发工具集：AVOS + Koding + Chromebook（假装我在用！）

AVOS提供了很好用的shell工具，帮助快速开发后端nodejs应用。既然Koding自称支持node，那肯定也支持AVOS啦。那我这次就要假装在Chromebook上，用Koding来开发一个基于AVOS的项目。

首先创建一个AVOS工程，云代码－下载项目框架－Web主机版。把这个button对应的url拷贝下来。

创建一个Koding工程，在Terminal里执行
```
wget "[之前的那个url]" -O code.zip
```
可能需要把https改成http。创建一个新folder，比如mkdir avosproj，把code.zip拷贝进去，然后再unzip。

在这个avosproj里安装avoscloud-code，npm install avoscloud-code

等安装成功以后就能在avosproj里执行avoscloud啦。正常的话执行完了就会跑起来一个server，点击左边VM里右边的三个点儿就能看到这个VM的public IP xx.xx.xx.xx。再开一个Tab，访问xx.xx.xx.xx:3000就能看到那个avos项目运行起来的样子啦！
(30 hackdays day 2) Diffbot – 问题来啦！（1）

10月 12th, 2014

挖掘机技术哪家强？严肃点，我们来认真讨论这个问题。
假设我们讨论的是哪家培训挖掘机技术最强。首先，我们得知道有哪些地方能够学到挖掘机技术。然后，我们要想个办法定义“强”。最后我们得能算出来结果。

挖掘机技术学校

要知道都有哪些学校教挖掘机，我能想到的就两个来源：技校的黄页，搜索结果。前者可能有专业的技校汇聚网站可以爬取到，后者可以用第三方的搜索服务获取。于是我Google了下“挖掘机技术培训学校列表”。发现前几条结果都是www.peixun360.com他家的，所以我决定先把这个网站的挖掘机学校列表爬下来。

Diffbot

Diffbot是一个帮助人们将网页数据转换为结构化信息（其实就是爬虫干的事儿）的在线服务。通过简单的点选网页上的信息，指定到对应的结构化信息。它就能帮你把一个网站的信息转换成一个结构化的API。换句话说就是一个普通用户也能爬京东，把某类产品的网页变成一个“excel”。

Diffbot的API基本都分为Automatic和Custom两种，前者不用做任何事儿，算法自动帮你提取信息，后者可以有更大的自由度。

Product API是Diffbot重要API之一，用处就是帮助你自动分析一个“产品”页面的信息。比如“潞城挖掘机精品班”（是的，我看到28913也惊了，但放心，后面不是连续的…）。扔给Diffbot以后就会分析出下面的信息。

是不是挺整齐的了？这还是我完全没有控制的情况自动提取的结构信息。下面我们来用下Custom API，也就是指哪打哪那个。

先创建一个Custom API的Rule。可以看到Diffbot提供的Product的基本信息已经有很多了，什么OFFER PRICE，REG. PRICE，SAVE AMT.，BRAND之类的。那我们来把品牌加上吧。

可以看到这里挑选一个域数据的方式很直观，鼠标选择一个Div，Diffbot就会帮你把它赋值过去。这里的小问题是它前端代码对中文的支持还有bug。但Save以后数据是正常的中文。当我们定制了一个新Field以后，这个自定义的Product的Rule就创建好了。这个Custom API也就能正常提取同类网页数据啦。
然后我就想试试Bulk API和Crawlbot。前者可以让你输入一系列的URL，比如几家挖掘机学校的详情页URL列表，后者可以爬取一个网站，从而对某些符合规则的网页调用Custom API。但…但…丫是收费API，而且…而且…我交不起的300刀一个月…所以…所以…不是我偷懒～

好啦，这就是一个帮助SB也能爬网页的产品啦～（我得想别的办法拿到挖掘机学校列表了…）明天见…
(30 hackdays day 1) Firebase – Rethink database

10月 10th, 2014

今天是第一天！按照之前的盘口数据，成功比失败差不多是1:1，这，的确给了我很大的动力…这篇文章我会讲述一个有意思的Real-time API服务，Firebase。Leanstack.io将这类服务称为realtime backend api，Firebase对自己的定位也是“A powerful API to store and sync data in realtime.”。但我觉得Firebase带来的更是一种新型的“数据操作的思维方式”。

Firebase是什么？

简单的说，Firebase是一个简化数据同步工作的API服务。现代的应用开发者常会用BaaS（Backend as a Service）来简化开发工作，原因很简单：大部分后端工程师做的大部分事情都是重复的，但却很容易漏洞百出的，而且扩展性需要完全靠这些可能没有几年经验的工程师来完成，基本会是个很脆弱的状态。而在前端工程师得意于例如ParseJS，AVOScloud这样的服务，可以更少的关心后端的时候，有一些蛋疼的应用又需要让所有终端保持数据一致。那这时候Firebase就登场了！

Firebase可以让所有终端简单的接入SDK后，就可以访问和操作一个云中的统一数据库。任何对其中数据的修改都会在极短的时间内通知到所有其他在线的终端。

Firebase能做什么？

最简单的应用场景就是聊天室啦。以前，想要写一个聊天的App有多难？后端工程师需要设计至少两个接口：Post message和Query message。而利用Firebase就可以把后端这工程师踢掉了。通过简单的创建一个聊天室Object（是的，Firebase中的数据只有Object，每个应用都是一个巨大的Object）。把自己想发送的内容添加到这个Object的messages里，类似chatroom.messages.push(‘啦啦啦’)。所有监听注册了这个chatroom的终端就都会得到一个数据变动的Event，从而拿到这个新的chatroom.messages用来更新聊天室内容。

哦对忘了说了，前端时间因为香港占中一炮而红的Firechat，其中Global聊天部分就是基于Firebase的。

如何入手

和所有的BaaS服务一样，Firebase的Get Started极度易懂，推荐采用Javascript的教程走完前三步就够了：Install，Save，Update。通过这三个步骤，一个Firebase的基本功能就展现出来了。

Object.set({ … }) 是直接生效的，不用再调用什么Object.save()

替代Object.get( … )的是Object.on(‘event’, function(data){ … })。开发者要思考的，不再是我需要多久更新一下这个数据，而是可以专注在每次拿到手头这个Object的更新数据的时候，我需要实现什么逻辑。

我实现的Demo

很早以前就想实现一个idea：我在卧室听有声小说的时候，突然要去上厕所。这时候我只要走出卧室，小说声音就会暂停，而当我走进厕所，厕所里的一个手机会继续卧室里的播放进度继续播放。也就是一个让媒体播放可以根据人的位置自动转移的新型体验。当然这也可以扩展到视频播放等。

检测人位置的功能我用iBeacon来实现。在两个距离较远的位置放置两台pad，上面运行着一个我的应用。应用所做的事情很简单：1. 检测用户距离多远。2. 根据服务器的指令播放媒体内容。

iBeacon SDK能做到的就是时刻告诉我周围的iBeacon设备距离我设备多远。而服务器用这些数据来实时判读到底应该在哪台设备上播放媒体内容。

这里Firebase的用法是

App将当前周围iBeacon的信息实时保存（默认情况下，每秒钟都会保存一次最新的数据）在某一个表示当前pad的Object下，用beacons的一个子子Object来表示。其中包括每一个iBeacon距离当前pad的距离。

一个Nodejs的Server。时刻检查着当前所有连上服务器的pad有哪些。一旦这里面有任何数据变化（某一个pad距离旁边的某一个iBeacon距离变化都会造成到root Object的数据变化事件），就会运行一段JS来判断当前哪个pad离用户最近，判断一下之前哪个pad在播放什么内容。如果最近的pad有变化，则将之前播放中的pad暂停，指挥新的pad播放该内容。如果没有在任何一个pad的范围内，则所有App都不会播放。

App会做的另一件事情就是根据当前所对应的Object下的一个域值：Settings里的一些配置来决定是否要提高或者降低亮度。记得前面说的吗，这个实现的方式并不是Object.get()，而是Object.on(‘value’, callback)，是不是很像JS里的observe。有趣的地方就是，这里的控制信号是通过一个类似数据库里的某个数值来完成的，而不是什么远程调用之类的。

总结

这样一个idea，通过引入Firebase，将一个终端App退化成了一个Sensor＋根据数据库某个数值来改变view的简单实现。而同步那堆乱七八糟的什么的，完全看不到了。是不是很酷～

Source code https://github.com/fxp/flowapp
30 hackdays

10月 9th, 2014

看了著名的Learning 30 Technologies in 30 Days: A Developer Challenge以后，我决定也要挑战一下自己。原作者是学习的基本都是一些好玩的技术，我会挑选工作中会用到的需求选择新技术来实现（新技术：以前没有使用该技术完成过项目）。然后我想叫它30 hackdays。我的目的，一来是好玩，二来是提高自己在正式项目中采用新技术的速度。

10月10日起，每天一篇比较正式的blog（文章质量参考原作者，第二天早上3点前发出算数）。为了好玩一点，我想用这个挑战玩一次对赌：参加的人只需要留下你认为我能否成功的判断，成功（30天）或者失败之后，我挨个请猜对的人吃串儿～猜错的人自觉请我吃～（所以其实我可以盈利的么…）

文章发在wordpress托管的博客www.fengxiaoping.com，墙内的同学不好意思了，可能加载速度比较慢，而且有些图片看不到。