创业者们(1)

这是个好时代,机会多到做煎饼都可以融资。然而很可惜,我们是做“软件外包”的,我们站不到风口上。

不过,用个不恰当的比喻,”没吃过猪肉,却见过许多猪跑“。我们见证了许许多多这场浪场中的斗士,或豪,或苦,或聪明,或愚钝。

今天我们讲个中国人在美国当老板的故事。

老板D先生开了一家滑雪用品店,经营有道,在滑雪圈小有名气,几年间赚了一些钱。在一次活动中,D先生了解到了社群营销的概念,大感对味,回家后认真研习并制定了公司下一步的计划——社会化营销加扩充品类,在未来两年内做户外用品+社群营销的平台。

找到了方向的D先生立刻开始召集人手准备大干一场。多年的经商经验让他决定找一个技术负责人来负责这整个业务。故事就从这里开始了。

想到技术,D先生本能的就想到硅谷。但打听了一圈得知一个工程师的平均工资大约在十几万美元之后,他决定去二线“硅谷”找便宜一点的工程师。

几经周折,次年1月左右,C工程师被D先生相中,成为了这个项目的技术和项目负责人。C工程师打包票说这个项目没问题,并且承诺半年内项目上线。开心的D先生吩咐了人事和财务全力支持C工程师以后,就转身回去调配资源准备大干一场。

说话间就到了9月,D先生在联络了多家供货商、社群营销、物流等合作伙伴后,开始准备对接到自家研制的平台上。另他惊讶的是,开发团队居然还是C工程师一人。难道是能力太强,一人都给做完了?D先生疑虑满满之下得到了C的答复,“现在页面太丑,我需要写前端的,人事没法招到我需要的人,只要招到就搞定了”。于是D先生开始吩咐手下的亲信帮忙招人。

一个月过去了,团队依然还是C一个人。“没有达到我标准的应聘者,就差前端的人了”。

又一个月过去了,C还是这个团队的Lead和唯一的成员。D先生忍不住了,通过朋友联系到了我们,让我们帮忙做前端。

“API都Ready了,Demo页面也有了,就差写HTML+CSS的了”,“预算也都没问题!”,听起来是个不错的项目。可是,当我们看到C工程师的代码库Github的时候,一年一共30多次的代码提交,仅仅在2,3月和10月份有代码提交的提交历史还是让我们心生怀疑。

这个项目后来证明,C工程师仅在2,3月份提交了系统的基础代码,在10月份提交了一些用于演示的前端代码。距离D先生描述的业务场景还相距十万八千里。

工程师是一个当下有点过誉的职位。事实证明,大部分工程师能按时按量完成手头的任务,但并不具备推动业务发展的能力。

所以,初期的创业者,如果那位技术创业者不是“另一个会技术的你“,还是把业务牢牢握在自己手里吧。

《说好的脑洞呢》

脑洞不是个贬义词,脑洞是生物,有些可以长成小草,有些可以长成暴龙,有些可能根本无法顶出地表。

《说好的脑洞呢》是一个新的系列尝试。我们想记录,讨论并分享这些有生命的突发灵感

《脑洞》的前身是一个叫Daydream的Trello board,现在依然可以访问,欢迎加入。

加入Mail list(holesinbrain@googlegroups.com) 或者关注我们的喜马拉雅电台来支持我们吧!

wKgDbVYMCcijPhKwAABuDRjbKRw148_mobile_large

(30 gadget day 8) 你爱我有几分 — Mindwave mobile

Mindwave EEG

Mindwave mobile EEG是一个一直以来我觉得Dev friendly做的最好的产品。
虽然开发起来依然不如Estimote,MYO之类的新Gadget那么方便,带maven带gradle,但就凭这么多年,当年的代码在android 5.0上依然可以跑,就足以欣喜啦。

那究竟它可以做什么?EEG是啥我就不说了,见Wiki。Mindwave mobile提供的SDK基于基础的alpha,beta数据,提供更有价值的注意力,冷静度,甚至眨眼的数据。当然,alpha,beta也是可以通过SDK获取的原始数据。

下面是官方应用的截图。
图片描述

client

这东西的开发很简单,尤其是android端。下载官方的SDK,把jar扔到你的项目里,就可以写代码啦。代码也很简单,拿到蓝牙Adapter,设置一个处理事件的Handler,连上设备。

    btAdapter = BluetoothAdapter.getDefaultAdapter();
    if (btAdapter != null) {
        tgDevice = new TGDevice(btAdapter, handler);
        tgDevice.connect(true);
    }

在发生了连接事件以后,启动设备以获取各种类型的脑波数据。除了设备状态转变以外,其他数据就都是业务数据了。其中也有两类:设备本身的数据质量,数据本身。数据质量里有一种很重要的MSG_POOR_SIGNAL,用来表示当前信号质量,这个数据主要用来描述EEG和大脑之间的接触良好成都。

private final Handler handler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
        if (msg.what == TGDevice.MSG_STATE_CHANGE) {
            switch (msg.arg1) {
                case TGDevice.STATE_CONNECTED:
                    Log.i(TAG, "connected");
                    tgDevice.start();
                    break;
                ...
        } else {
            switch (msg.what) {
                    case TGDevice.MSG_POOR_SIGNAL:
                        signalTextView.setText(String.valueOf(100 - msg.arg1));
                    case TGDevice.MSG_ATTENTION:
                        Log.v(TAG, "Attention: " + msg.arg1);
                    ...

        }

你爱我有几分

前几天听到一个笑话:某工程师的妹子问他“你爱我有几分?”,答曰“8.5分”,“你爱你前女友几分?”,答曰“9分”。

但不说情商为何物,只缘分数还有小数点。不过从科学角度,我们倒是可以把注意力当做一种衡量标准。比如某PM问用户“你爱我们产品有几分?”,这时,用户的注意力就可以当做一种比较“本质”的回答。

Attention driven design

所以也许,用户的大脑状态可以是另外一种产品设计的基础。例如,我希望用户看到我的产品之后两分钟内都能保持高度注意力,那就可以用这样的技术来测试,甚至在产品设计阶段做简单的用户调研。

比如下面的图是我在写程序时候的注意力分布图。如果采用WakaTime类似的技术记录下我所有在IDE里的操作,就能够分析出IDE里每个功能的使用对应我的注意力,从而对功能设计作出调整。

图片描述

当然,根据每一条代码对应的注意力,也许就能作为代码检查的另外一种依据。“糊涂的代码”是个认真的说法。

Mindwave in cloud

作为QS的支持者,我当然希望我的所有数据都能数据化并保存下来。Mindwave mobile给我提供了很大的便利,很容易的将我简单的脑波数据保存下来。

具体的用处嘛,既然Apple watch都出了ResearchKit,就不用解释啦~但另一个可能的用处,也许就是我可以“出卖”我的数据。比如A网站是个codeshool类的产品,产品想知道某些教学视频到底做的好不好,有没有趣味,作为真实用户的我就可以根据需求用我真实的,具有严格时间戳的脑波数据来换取一部分好处。

我管它叫Cloudmind,目前是基于Leancloud+chartjs,可以持续积累数据。但由于没啥内容外加代码太惨,暂时就不扔出来啦。

关于这个功能我是认真的。所以,如果有哪个产品想获得我使用时的脑波数据以用于产品设计,请联系我哈~

最后,来看看我眨眼的样子:)

图片描述

图片描述

(30 gadget day 7) 姑娘,请问您的相位是多少 - SmartScope

今天嘛…本来想写structure sensor的,结果发现SDK超难用。然后想写Muse EEG,结果发现Muse的SDK需要把数据从Mac proxy过去才能用。妈蛋,你们SDK做这么烂怎么跟Mindwave拼…

最后只得挖出SmartScope。官网逛了一圈,唯一的感觉就是,这产品要挂了。完全没有人维护的社区,基本没功能的Demo app,据说ship产品以后就开源的github账号拥有0个repo。anyway,有啥东西可以用示波器来玩呢…

好吧,事先提醒下,今天没代码…

SmartScope

SmartScope当年在kickstart上众筹的时候,就让我一见倾心买了连接ipad的版本。结果几个月之后才发现他们一直在发一个mail催我补缴运费,我一直没理。好,货到了,发现ipad的连接线却没有…就这样抵运费了,真的好么…它就长这样。

图片描述

Foc.us

说到电流,立刻就想到了Foc.us,那个可以把电流注入到你大脑里的玩意儿。那就用这玩意儿看看它呗。打开Foc.us,连通,开始放电。

图片描述
图片描述

选择个正弦波。

图片描述

看这个波的样子。

图片描述

看起来只要把频率调一调就能看到一条漂亮的正弦波啦。看ze里,看ze里!

图片描述

所以结论就是…foc.us说的是实话…

naked iBeacon

好吧,文章这么短不好。我们再找个有电路的玩意儿~手头有几个没电了的Estimote,来妞儿,打开让我看看!嗯,正好有新的CR2450,来,复活吧!

图片描述

但问题来了…哪里有inspect的地方呢…好不容易找到四个触点。好吧,就让我们以猜公母结束吧,猜猜哪两个是一对儿~打开一条Math线,设置为A-B。捅来捅去吧。math线接近0的就是同一边儿的。好吧,知道你们也不在乎…

图片描述

知道为啥我不介绍其他类似decoder的功能么?因为他们还在coming soon!!!还在coming soon…

晚安~又混过去一天!

(30 gadget day 6) 主人,早上好 - iBeacon

咳咳,今天遍寻各处都想不到写个啥。于是只能假装我没玩过这个“新鲜”的gadget啦——iBeacon!

问候

办公室人少,每次去的时候都略显孤单。于是决定写一个跟自己打招呼的玩意儿,让我每次进门的时候都能收到一个“亲切的问候”,比如。

图片描述

iBeacon with Web

据说微信的JS SDK要开放iBeacon的部分了。所以嘛,先prototype一下咋用js来玩ibeacon。我先猜测下哈,微信的SDK是估计是把native的ibeacon数据通过微信转换以后bridge进H5应用里,也就是假设某个ibeacon对应的是吉野家某个门店的大门口,然后用户无论通过何种入口(摇一摇,扫二维码等),进入了一个开发者设定的H5页面里。在这个页面通过类似wx.beacons接口拿到了周围的ibeacon数据。这种数据应该是某个url,某个商家,某个门店,某个位置这样的,而不是类似UUID,major,minor这样的标准ibeacon id。

我想做的更简单一点。native app拿ibeacon数据,把数据同步给服务器,服务器确定是否要触发事件,如果需要则发给H5应用。这样的问题就是,要总连着网。so what,嗯。

iBeacon检测

家里的Estimote iBeacon都没了,只能用不熟悉的Kontakt的啦!他们长这样。

图片描述

去官网看文档,跳到Android的GetStart,直接搜“download”,果断看到“Go to the Kontakt.io Android SDK 1.0.5 on GitHub”,看到两个jar,直觉都当下来,回来看文档,都拷进去就好。

然后肯定就是加Permission啦,文档搜一搜,发现相比Estimote,Kontakt对权限分的更细一些,如果你不用他的云服务就不用加Internet权限。还有不大明白为啥针对萝莉炮要再加个Service,这都不能检测下么。

<service android:name="com.kontakt.sdk.android.manager.BeaconService" android:exported="false"/>
<service android:name="com.kontakt.sdk.android.manager.BeaconServiceL" android:exported="false"/>

然后就是看具体怎么用啦。无非也就是创建个BeaconManager,收各种回调哈。

        beaconManager = BeaconManager.newInstance(this);
        beaconManager.setMonitorPeriod(MonitorPeriod.MINIMAL);
        beaconManager.setForceScanConfiguration(ForceScanConfiguration.DEFAULT);
        beaconManager.registerMonitoringListener(new BeaconManager.MonitoringListener() {
            @Override
            public void onMonitorStart() {}

            @Override
            public void onMonitorStop() {}

            @Override
            public void onBeaconsUpdated(final Region region, final List<Beacon> beacons) {}

            @Override
            public void onBeaconAppeared(final Region region, final Beacon beacon) {}

这里文档有点问题,新的1.0.5的SDK里已经不是Beacon这个类而变成BeaconDevice了。connect函数里也有不一致的地方。startMonitoring的参数要清空就好了。不然就自己弄个Set,找个Everywhere的Region装进去。

    private void connect() {
        try {
            beaconManager.connect(new OnServiceBoundListener() {
                @Override
                public void onServiceBound() {
                    try {
                        beaconManager.startMonitoring();
                    } catch (RemoteException e) {
                        e.printStackTrace();
                    }
                }
            });
        } catch (RemoteException e) {
            throw new IllegalStateException(e);
        }
    }

数据中心

我一直希望把自己的各种数据尽量实时的扔到云里去,这样几十年以后就能知道现在的我是怎么活的啦。这里我也不希望搞个啥local server之类的,直接上云服务吧。以前介绍过PubNub就是个和Firebase类似的实时数据库。客户端和服务器端可以用超高抽象的handler来操纵数据。

这次我用PubNub来实现。GetStart就跳过了。看名字就知道这玩意儿是在做PubSub类似的技术。所以程序也很简单,一端Pub一端Sub。既然是手机端发现iBeacon那肯定是手机端来Pub喽。服务端就把事先知道的iBeacon都Sub上就好了。channel就用每个beacon的uuid:major:minor合起来hash一下哈。

Pubnub pubnub = new Pubnub("xxyyzz", "status");

try {
  pubnub.subscribe("hello_world", new Callback() {
...
// 也可以直接抄一下昨天hue的api body,挺像的
pubnub.publish("xxyyzz", "{"status":"on"}" , callback);

我来啦~

前端页面引入PubNub的库,每个设备都显示自己对应的页面,然后就Sub着就好啦。一旦有消息进来,就根据status选择性display那张图哈。

困死了困死了>.<

另外,求各种带API的硬件Gadget…库存快枯竭了…

EOF

(30 gadget day 5) 那棵灯 – HueMyo party

Philips的hue灯泡算是智能灯泡的鼻祖了,这次就来玩玩这个哈。

meethue

meethue.com是hue的门户啦,有各种的使用说明。开发者的入口在哪呢…找了半天发现右边有竖着的developer…

图片描述

好吧,进去以后直奔Get started。大概扫一圈以后发现这个hue的bridge设计的还真不错,直接通过http就能访问到api的测试后台。

图片描述

  • 认证
    只要改url和body就能直接控制灯泡。然后发现都是unauthorized。于是回来看文档,发现需要按一下bridge的button,然后立刻发个下面的请求就能认证上。之后的所有请求就都ok了。以后就可以用/api/newdeveloper/lights/1/state来控制这个id为1的灯泡啦。很标准的JSON RESTful API,设计的不错!
    不过这个不意味着我跑到任何一家有hue的地方,按一下按钮执行一个程序以后就可以躲门口随便玩他家的灯泡了…
POST http://<bridge ip address>/api
{"devicetype":"test user","username":"newdeveloper"}
  • 修改灯泡状态
    每个灯泡都有一个url作为它的endpoint,可以对它肆意GET POST PUT。比如让它打开就curl一下。色温(sat)亮度(bri)和颜色(hue)控制起来超容易!
url -X PUT -H 'Content-Type: application/json' -d '{"on":false, "sat":255, "bri":255,"hue":10000}' http://192.168.31.xxx/api/newdeveloper/lights/1/state

MYO控制HUE

哈,MYO又出现了!上次只拿了pose的数据,这次我想让灯泡跟着挥手变换颜色,那就要获得当前手臂的角度啦。代码的区别只是多加个回调就好啦。能拿到一个4维的数据。xyzw。

        @Override
        public void onOrientationData(Myo myo, long timestamp, Quaternion rotation) {
            ((TextView) findViewById(R.id.hello)).setText(
                    "Z:" + rotation.z() + " W:" + rotation.w() + " X:" + rotation.x() + " Y:" + rotation.y());

        }

通过观察发现挥手的时候变换的很多的是w轴,而且右手挥动的过程正好是-0.5到0.5的过程。好啦,现在把这个数据随时记录下来,每秒钟发个PUT过去改灯泡的状态。咱就用OkHttp搞好啦,类似这样。

    String updateHue(int bright, int hue) throws IOException {
        OkHttpClient client = new OkHttpClient();
        RequestBody body = RequestBody.create(JSON,
                "{"on":true,"bri":150}");
        Request request = new Request.Builder()
                .url("http://192.168.31.xxx/api/newdeveloper/lights/1/state")
                .post(body)
                .build();
        Response response = client.newCall(request).execute();
        return response.body().string();
    }

Party!

好啦,就这样!

图片描述

Party呀

(30 gadget day 4) 那边有把吉他,所以 - MYO (2)

今天我终于把MYO搞好了。之前无论如何都Update不动,搜了下发现可以用“直连线”强制升级。Anyway,让我们开始想想这玩意儿能玩啥吧!

又到了这个点儿,家里又只剩下YubiKey等超弱智设备陪着我。就只能打打擦边球了,用手机来充当Gadget吧…

看了一圈MYO的market,发现基本之前想的一些场景都有人实现了。比如用手势来操作chrome,操作鼠标,地图,游戏,甚至trello。

好,吧,惆怅了,写个啥呢…

有把吉他

图片描述

抬望眼,看到有把吉他在远处蓬头垢面的看着我。再看我…再看我就拿你开Live!

嗯,万事具备,只差我不会弹,and没有粉丝了…

好,吧,那写个粉丝呗。请想象一下…“爷弹了个和弦,观众就掌声雷动!” O.O >..<||

图片描述

校园API化

图片描述

以前应人邀请写的个东西,结果人家说看不懂哈,那就发在这里啦。

在我心目中,理想的校园应该是个大实验室,学生和老师在其中学习了解各种知识,实践尝试各种创新的想法。而在这个人人都在喊“大数据,物联网”的时代里,校园更应该是最活跃的实验场。

当我们讨论iWatch,iBeacon,Oculus这类新型的可穿戴,物联网技术的时候,可能都隐约意识到其中所蕴含的变化的内涵,在这些人与环境,人与人,人与自身感官之间交互方式的转变背后,其实是人类社会自身数字化的过程。在这里我只想就这种数字化的构想做一些想象,设想一些在校园内可能的数字化实验的场景。

API的力量

API是应用程序接口(Application Programming Interface)的简称,一般用来指代系统的不同模块之间通信的约定。Wiki中解释API设计的目的:“程序设计的实践中,编程接口的设计首先要使软件系统的职责得到合理划分。良好的接口设计可以降低系统各部分的相互依赖,提高组成单元的内聚性,降低组成单元间的耦合程度,从而提高系统的维护性和扩展性。”。由于现代系统的复杂度非常高,人们不得不将系统划分为大量基本模块,这就使得合理的模块间通信设计变的十分重要。

对于工程师来说,提到API,多数会想到那些可以弹出个对话框,把一些字符串拼到一起这类软件开发工具(SDK)。但对于许多新公司而言,API代表的是更高级,更抽象的服务,而这些或多或少的已经成为了公司核心的一部分。

如果我们现在创业做一款产品,所需要的大部分技术工作都可以寻找到对应的API。底层的如提供服务器托管的阿里云,直接服务应用开发者的的LeanCloud;应用层的如用语用户反馈的Uservoice,可以完成大量复杂数据分析的Mixpanel;再到直接提供机器学习算法服务的algorithms.io,专门提供图像内容识别服务的Rekognition。可以说,开发者需要的基本工具,都能以很低廉的价格,以服务的方式获取到。而这些服务,就是新一代的API。

新一代的API不局限具有更广的“光谱”:小至算法(algorithms.io),大至企业帐目核算(Mint.com),银行资金托管(bancbox.com)。这些服务现在都在或多或少的以一种“可编程”的形式出现。这就使得原来需要人力去“粘合”才能保证企业运转的工作,比如员工招聘,会计,行政的工作,都可以被程序更高效的替代。

我相信,能够善用这些新API(也就是擅长Mashup),将是未来工程师的重要技能。所以,我模仿了国外的一个博客系列,Learning 30 technologies in 30 days,也开始了自己的30天30项技术的30hackdays系列,可以在segmentfault的博客看到。

未来的人工智能是网状的。前面提到了algorithms.io这样的产品,可以给那些完全没有机器学习算法经验的团队提供复杂的算法服务。而近些年,类似的产品(服务)也出现暴增的趋势,如出门问问,Tuling123,虫洞助手这样的智能助手产品等。这意味着,原来被视为大公司才能拥有的人工智能服务正在被一个个细小的产品分食。这些微型智能服务从许多小需求点切入,并且尽量大程度的开放API给其他开发者。一方面提高了自己产品的生存能力,另一方面也为以后形成微型智能服务之上的中型智能服务奠定了基础。

假设某个开发者想实现一个检测橱窗里海报被关注度的产品,他完全可以购买一款可以通过API访问当前视频流的摄像头放在海报版前面,将数据流分别导入一个提供OpenCV的服务和一个如Amazon EMR的大数据存储平台中,在获得当前板子前的同学的轮廓以及朝向后,将这个数据分留给如chartbeat这样的实时数据分析平台,以及提供用户行为预测服务的Framed Data类平台。最后将得到的分析结果输出给Mixpanel这样的数据可视化平台。这样就借助许多第三方服务完成了一个看起来每个点都需要很大工作量的系统。

释放巨龙的力量

算法已经被充分互联网化,甚至服务化。但现实世界在这方面就落后的多。物联网算是离人们最近的数字化技术,但人们目前可以接触到普及了的相关技术也就是NFC和短期内可能兴起的iBeacon技术。机器人算是填补这个沟壑的重要手段。通过大量的传感器和具有实际干预能力的机械装置,机器人可以实现充分释放“淤积”在互联网中算法的巨大力量。

除了最近火到黑的Jibo家庭机器人,比较低技术含量的家用机器人也已经崭露头角。如添加了各种传感器的联网扫地机器人,微型飞行器,联网的空气质量监测器,这些设备的根本目的都是将人们周围的环境量化,将数据传入云中,利用算法的力量来尝试解决实际问题。为什么叫尝试解决呢?第一,这里的问题可能在拿到一定数量的数据之前都是未知的,只有到了“大数据”的量级,问题才会浮出水面。第二,除了那些明显通过改进算法可以解决的确定性问题之外,发现那些原来并不存在因果关系的,只是概率上存在关联的问题会成为算法的重要责任。这也就是为什么在中型规模的智能服务没有兴起前,所谓的智能家居也只是“App上的开关”的原因。

校园,变革的前线

生活在校园中,我们肯定经常遇到到某些不便,去自习室看书却不知道哪间教室人少;去操场打球却要花很长时间招呼朋友;去图书馆借书却又找不到XY书架在哪。这些问题的本质都是信息的不对称。过去人们通过发明电话,地图等方式来辅助人们减少这种不对称。而大数据时代的做法则是,API化一切,利用算法的力量解决物理世界的问题。

正如前面提到的,API化包含两方面含义:对物理世界的数据化,以及数据的物理化。前者指的就是通过各种各样的传感器,将物理世界的各种表相转换为可以被算法处理的数据信息,比如各种监控摄像头所存储的校园内的影像信息。后者指的是将以上数据处理以后的结果转换为实际的物理行为,比如荷兰设计师设计的可以跟随人的椅子,Take a seat。

在学校中,我们可以做些什么API化的尝试呢?

安全。相比社会,学校一般还是更安全的地方,但一旦出现事故在社会上的影响也是更严重。所以如果学校能够将学生的位置,比较实时的获取到,在保证学生隐私的前提下,检测每个学生的安全程度。一旦发生事件,学生可以很容易的报告学校保安部门,也许就可以及时阻止可能的危险行为。这在技术上并没有难度,每个学生几乎都有智能设备。通过在室内增加一些诸如iBeacon的设备也可以更精准的定位学生的位置。但正如前面所说,学生对于隐私的疑虑也许会高于对自身安全的担心。

社交。基于如上的安全产品,学校的学生位置就已经被API化了。除了Dota,撸啊撸以外,学生关心的应该就是社交了。做校园社交的产品很多,但由于各家都不会开放自己的数据,所以在使用不同产品的时候都需要重复填写很多信息。这个问题对于职场人来说没有多大问题,因为大家都在几个大的社交平台活动,如linkedin,facebook等。但学生会具有更多细化的筛选需求,比如某个院系专业的,正在选修某些课程的。课程格子在这方面做了很多有趣的尝试。

开放。学校应该建设自己的数据开放平台,为学生提供实现上述类型想法的最基础设施。比如在教学楼内部署温度湿度红外传感器,并将这些数据同步到网络中供大家访问。这个时代的开放校园,除了开放的课程以外,学校的公开信息,甚至一草一木的数据都应该被开放出来供大家访问。

双刃

另一方面,美剧《Person of interests》讲了一个大数据的另一面,一个令人很恐慌的黑暗面。政府建造了一个监控所有数据的机器,由此发展出了智能,反过头来干预现实人们的生活。就目前的技术发展来看,很有可能片中的情况已经发生,只是我们被机器“照顾”的很“正常”,并没有意识到另一个“大意识”的存在。

算法的力量已经开始渗入普通人的现实世界。《互联网思维与我们的未来》一书中的海妖服务器即将成为未来的游戏规则。尽量接近“核心算法”,找到自己的位置,至关重要。

(30 gadget day 3) 绝对的小个子-littlebits cloudbit

做技术启蒙教育的可能都听说过littlebits,一堆小小的工作单元,通过磁力轻松的连接起来,就可以实现一些简单的电路逻辑。比如,把电源-按键-LED串在一起,就能实现一个“按键让灯亮”的小电路,也不用担心电路接错了会烧坏元件啥的。

图片描述

逗我玩么…

当然,爷会只玩这么白痴的东西么…如果有孩子了的话还是有可能的…转个推

@Tomy 偶然发现一个程序猿的各种 SNS 帐号都在2012年之后停止了更新,博客、微博、Twitter、V2EX 都没有了音讯,就连 Github 2013年后都没再提交代码了!!怀着恐慌的心情 Google 了下 ID,发现了他在2014年海淘了几袋奶粉的晒单……心情的跌宕起伏,是为记

好吧,我承认这是混字数。你走开!我之所以买了一套littlebits呢,就是看中了新推出的cloudbits——一个可以联网控制的元件。

图片描述
图片描述

Cloudbit

玩IFTTT的同学应该都注意到有一些菜谱里面出现了这个小笑脸,这玩意儿就是cloudbits。

图片描述

简单的说,Cloudbits就是一个可以联网控制的littlebits组件,而就是这么简单的设计,给littlebits带来了无限的可能性。littlebits官网首页的展示视频里有一个小情景:猫猫按了一下littlebits的按钮,主人手机就蹦出来一个“feed me”,主人点一下feed,猫粮就掉下来了,这个情景的实现就完全倚赖cloudbits的推出。

Cloudbit get started

setup的过程如下:

  1. 登陆Cloudbit控制后台
  2. 按指示连接到Cloudbit的wifi
  3. 帮助Cloudbit登陆本地wifi
  4. 切换回本地wifi,等待cloudbit的灯从绿色闪烁变为绿色持续(这个过程我搞了好几次,可以试试拔掉Cloudbit再插上,TroubleShotting里也有一些有用的东西)

p.s.
悲剧的是我发现我这个单元的reset按键坏了,基本可以判断总是按接通状态。于是…就总是处于reset,reset的循环中…最后就只能把那reset键给拆了…

图片描述

反正最终的结果就是这样

图片描述

这个大按钮的作用呢,就是让这个Cloudbit想外发送数据(其实就是提供电压,还可以调节输出电压的数值,当然是从0到100这样的方式)。

Develop with Cloudbit

具体的玩法就不说啦,里面核心的就是如何将Cloudbit的输入输出与网络服务结合起来。先看API文档吧,没想到API已经到v2版本了。

Auth

littleBits的API支持标准的OAuth2,DeviceID和Token从后台就能看到。用这两个值就可以完成认证。

图片描述

Endpoints

                                ---Responds---
                              OAuth   HTTP
path                          Scope   Code  Payload ◆       Make LB Cloud...
----                          -----   ----  ---------       ----------------
/devices
  GET                         read    200   [<devices>]    return a list of the user’s devices

    /{device_id}
      GET                     read    200   <device>       return device model
      PUT                     admin   200   <device>       update device model
      POST                    admin   201   <device>       activate device, is then associated to the user
      DELETE                  admin   200   <device>       deactivate device, is then associated to no body

          /output
            POST              write   200                  output some voltage on the given device

/subscriptions
  GET                         read    200   [<subs>]       return device's subscriptions
  POST                        read    201                  publish given device events to given endpoint
  DELETE                      read    200                  stop publishing given device events to a given endpoint

赞这个“文档”,极简又足够清楚。先拿一下这设备的信息。

curl -i -XGET -H "Authorization: Bearer e352c8d9f7a9103c59xxxxxxxcdb6c5b28fbd6c2c438936xxx" -H "Accept: application/vnd.littlebits.v2+json" https://api-http.littlebitscloud.cc/devices/00exxxxxxx39

response

{"label":"office","id":"00exxxxxxx39","user_id":35515,"is_connected":true,"ap":{"ssid":"senz_xiaomi","mac":"8C:BE:BE:28:15:6B","strength":"100","server_id":"7yY9Dniw","socket_id":"7JeMsZ2w"},"subscriptions":[],"subscribers":[],"input_interval_ms":750}

看起来没啥用呢…再回来看Doc,output的部分看起来容易用哈。

curl -i -XPOST -H "Authorization: Bearer e352c8xxxxxxfbd6c2c438936e0b97cebb8b7" -H "Accept: application/vnd.littlebits.v2+json" https://api-http.littlebitscloud.cc/devices/00exxxx39/output -d percent=50 -d duration_ms=1000

结果呢,就是灯亮了1秒钟!宏大吧!>.<

在WordPress.com的博客.

向上 ↑