3年养肉的成果

秋天到了,天气冷起来,多肉们进入了所谓的状态,虽然很漂亮,但是实际上对多肉的考验到了。

养了3年多,从同事那儿继承来的,虽然都是普货,但还是连一片叶子也不舍得丢掉。从春天起开始放到窗户外面的阳台上露养,历经早春的春寒,夏天的暴晒、暴雨、介壳虫,终于到了秋天,有了自己的颜色。

下周就该搬到室内过冬了,赶快记录一下它们最美的状态。

老桩,根部爆多头
老桩,根部突然爆多头哦
历经磨难,终于修成正果
多次砍头,坚强地活下来并且成功把盆占满
根部死了多次,最后砍头下来,秋天进入了状态
果冻色
据说叫法师
熊童子,长的太茂盛,也不变颜色,繁殖起来不容易
终于看到了传说中的多肉开花
菊丸森里,等大一些搞老桩吧
悄悄地爆了盆,把我的火龙果挤得没地方了
用瓜子皮做营养土,搞出的拼盘
拼了好多种,有熊童子、桃蛋等,没想到它的颜色最漂亮
大概这个符合某些养多肉人的审美
五朵金花,从大到小排列,自然的选择
从一片叶子发展起来的

ThinkPad的另一个乐趣

今天把一台老的ThinkPad T440P的屏幕从换成1900*1080P了,换完之后终于体验到14寸屏的优势了。之前的T440P虽然是14寸,但是分辨率是1366*768,总感觉可显示内容少。偶然从网上看到ThinkPad的X240可以换屏幕到1080P,所以萌生了把手上的T440P换个屏的想法。搜索了一下,真的可以自己动手换。赶快上某宝,搜索了一下,260多,找到一个付款人数多的店,下单,之后就是等待快递了。大部分的店都是广州深圳的,快递还是要一段时间的。

终于今天到货了,小心翼翼地拆封,先用手机上的手电筒照了一下,看屏幕是否完好,还好,没有裂,剩下就看有没有白点了。

整个换屏过程非常简单,普通小白就能干。ThinkPad T440P的屏幕边框都是卡扣的,从左边用指甲抠一下就能翘起来一点儿,然后慢慢把周边都抠开。还是要小心一点儿的,万一卡扣坏了,虽然没多少钱,可以再买,但一定会影响拿到新屏的心情啊。拆之前一定要断开电源,也要把电池拿下来。比较幸运,顺利把板抠下来。再用附送的十字螺丝刀把四角的4个螺丝拧下来,原来的屏就只有一个排线相连了。排线上有一个小铁丝的卡扣,轻轻翻过来,再慢慢地把排线分离。屏幕就整个下来了。之后把新买的屏的排线原样插回去。先别急着拧螺丝,先插上电源,开机,看看屏幕能否点亮。运气不错,一次点亮,而且在黑底色下屏幕无亮点。进windows系统,结果黑屏。多亏我装了双系统,平时更多地用Linux,所以重启进入Linux,一切正常,启动x-window,正常,调整屏幕分辨率,终于看到1900*1080了,表明屏幕是对的。之后关机,拧螺丝,再把屏幕边框安回去。换屏就结束了。

问了下客服Windows黑屏的问题,回复说只要强制关机重启就可以,试了一下,Windows下正常显示了。只是感觉机器似乎变慢了。也许只是感觉,也不排除分辨率高了之后系统变慢。后面慢慢调了。

经过这一轮折腾,觉得ThinkPad终于又多了一个乐趣:DIY改装。从常见的SSD硬盘,到屏幕,还有人直接升级了CPU。之前用过一段时间Macbook pro,总觉得空间不够用又不方便升级。少了定制的乐趣。把旧的ThinkPad拿来折腾也是一种享受。

在技术运营中如何提升团队技术软实力

当项目或产品进入到运营阶段,技术人员的工作内容通常会从大块的功能开发进入到运营活动开发、功能修补。时间稍长,开发人员会觉得在做重复性工作,没有新东西可做,从而缺乏热情。

但实际上,在技术运营阶段是提升技术人员能力的关键阶段,所以作为技术管理者,要做好引导和规划。

稳定性,性能,监控,运营工具、可重用是在运营阶段要提升的重点,而在项目开发过程中,这些事情要么因为赶开发进度而被忽略或搁置,要么没在线上检验而问题没有被发现,通过运营阶段的一系列工作,可以使开发人员全面了解在项目运营、系统运行过程中的真实需求,从而为提升今后的架构设计能力打好全面的基础。

一个有思想的好的技术人员在运营阶段可以实现自驱动,但大部分人需要技术管理者进行引导和规划。

技术管理者在此过程中要承担的角色:

  1. 技术运营指标的制定者
    1. 要梳理和定义好技术运营指标和评估标准与方式,并根据实际情况定义好分阶段目标
    2. 跟团队成员充分沟通,使其理解每个指标对于项目运营的价值和意义。
  2. 当前项目问题的发现者和改进推动者
    1. 要不断总结遇到的运营问题,不放过任何一个bug,从而发现可能隐藏的技术问题
    2. 通过code review等方式来发现隐藏在功能之下的代码问题
    3. 发现更好的解决方案和实现方式
  3. 技术团队的领导者
    1. 要从实到虚,再从虚到实,让团队成员真正认识到技术运营阶段自己提升的目标、方式和方法,从而达到团队成员的自驱动改进
    2. 用指标和评估来驱动团队的运行,用不断改进的指标数字来让团队成员看到成长和改变
    3. 培养团队的人才梯队,要让重点培养对象在过程中独立承担并完成日常工作。一定要培养团队的二把手。
    4. 不断分享工作中的成功与失败,打破分工的界限,让团队成员在日常工作中不断成长


游戏行业将进入机器学习时代

游戏从业者都知道,游戏的成功率低,即使做出过爆款游戏的团队也鲜有持续成功的案例,每个人都在自问:我的下一个爆款在哪里。

作为创意型产业,游戏的策划、开发、运营经验经常说不清道不明,甚至游戏圈的资深人士曾说过:你挖我们的主策划都没什么用,因为我们也不知道我们的游戏为什么火的。

一款游戏的设计、开发、运营、发行涉及方方面面,影响因素很多,策划和运营人员的经验又偏感性,很难简单复制传播,从而造成游戏的成功可复制性很差。

随着神经网络等机器学习技术的进步,通过对游戏历史数据、玩家游戏行为进行机器学习,从而将策划、运营等的经验进行量化,不仅可以用于评估游戏的成功可能性,而且可以预测玩家行为, 为玩家提供个性化的游戏内容,从而在提高留存、付费等方面带来颠覆性的改进。

机器学习将应用在游戏的设计、开发、运营、市场、发行的各个环节。机器学习是以大数据为基础的,有长期游戏运营数据的开发商、发行商、平台将在游戏的机器学习时代逐渐形成行业壁垒,确立核心竞争力。
小游戏厂商除非在游戏类型等方面创新,或者接受上述有数据的公司、平台的反哺,否则在成熟游戏类型方面的空间将进一步压缩。现有的游戏的开发商、发行商如果不能顺应机器学习这个发展方向,在不久的将来,很大可能会被淘汰。

机器学习在游戏中的应用的优势
传统的游戏分析主要是统计、分析,通过统计玩家群体的整体的留存(次日/3日/7日/月等长短期留存)、付费率、arpu/arppu、LTV等指标,通过人(数据分析师、策划、运营)来分析并发现问题,然后通过AB测试等调优手段进行优化。
传统的统计分析手段应用在游戏中,面临几个方面的挑战:
1、影响因素过多,“人”在确定各因素的影响系数时力不从心,分析的结果比较单一。
2、统计、分析的结果是群体性指标,面对单个个体的分析很少。
3、对于预测、改进的帮助有限。

机器学习的强项正好是在复杂的多因素环境下找到规律,从而弥补“人”统计分析的不足。另外,机器学习的学习对象和验证/预测对象都是个体,从而能够在对游戏的改进过程中提供个性化和有针对性的改进措施。

关于技术管理岗位的目标与职责

技术管理岗位目标

技术主管:其岗位目标是分解和分配开发任务,保证团队按时完成开发任务,保证开发质量,解决开发中遇到的问题。在此过程中培养团队的后备力量,提升团队的技术能力,保持队伍的稳定性。

技术经理:其岗位目标是总结和梳理技术部门的问题和发展方向,制定改进措施和执行方案,推动相关工作的落实。在此过程中培养技术主管的能力,提升部门在整个公司的业务体系内作用和重要性。

技术总监:其岗位目标是根据公司的业务内容和方向,制定技术部门的工作目标,探索和开拓新的业务方向,或者为新的业务方向提供决策和支持。在此过程中要把控各技术部门的目标、方向,帮助技术经理提高对业务的理解和管理的能力。

CTO:其岗位目标是以技术驱动的视角来探索和确定公司的业务方向,评估业务的成本、收益,分解业务目标、协调资源、组织实施,及时发现问题并进行调整,保证公司的业务目标能够达成。

岗位能力提升的关键点:

技术主管到技术经理的转变的核心在于总结能力和自我驱动能力。如何发现改进点和在没有明确目标的情况下梳理出工作目标,是技术主管与技术经理的职责差别。

技术经理到技术总监的转变的核心在于对业务的了解和理解。不花时间了解业务的技术经理是无法跨越到技术总监的级别的。

技术总监和CTO之间的差别在很多公司是不明显的,特别是在中小型公司。很大程度上取决于经验、所了解到的信息、与公司决策层的关系等。



炒币高位套牢后的正确解套方式

币圈炒币,被高位套牢是常见现象。怕上车晚了赶不上这波行情,所以在高位买入。结果买入之后行情大跌,从山顶一路跌到山底。有些人遇到这种情况,直接挂一个高位卖单,然后就不管了,美其名曰“佛系炒币”。

佛系炒币真的管用么?经过两轮大悲大喜,终于悟出了高位套牢后的正确解套方式:在下跌区间中及早卖出成USDT,在跌到谷底附近再次买入。在此过程中,还可以根据行情做一些小波段,赚一点回来。

举个例子:14.8USDT时买入100个EOS,一路狂跌,现在跌到4.5USDT。如果在跌倒10USDT时果断卖掉,获得1000个USDT。那么即使在跌到5USDT左右时买入,你可以获得200个EOS。那么如果币价开始回调,只要币价涨到14.8*100/200=7.4USDT的时候,你就可以解套了。这要比“佛系炒币”等到涨回14.8要有希望得多。

开发基于以太坊智能合约的DApp

最近要找个H5的前端写个简单的DApp,聊过几个H5的工程师,都被跟以太坊交互的部分吓住了。虽然网上有N多的教程,但是对于H5工程师来说,还是有些困难。分析其原因,在于不了解ganache-cli(原来叫testrpc)/web3/以太坊节点/metamask之间的架构关系。

梳理一下架构关系:

web3.js与以太坊通信是通过rpc的方式实现的。

以太坊节点本来提供了rpc的访问方式,但是因为以太坊节点的地址不确定,并且DApp需要访问钱包,所以用web3.js直接访问以太坊节点的rpc服务是不现实的。

ganache-cli模拟了一个以太坊的测试节点并提供对外的rpc访问方式(就是例子里经常说的http://localhost:7545或者http://localhost:8545)。同时在其中内置了M个以太坊帐号,用于测试。

MetaMask是一个以太坊的网络钱包插件,它也提供了web3的访问方式。而且可以通过这个插件指定后面的以太坊节点是什么。因为MetaMask是个钱包插件,所以解决了DApp中的支付问题。所以现在的DApp都依赖它。

开发DApp的基本过程如下:

1、安装NodeJS

2、安装truffle:一个开发DApp的开发框架

nmp install -g truffle

3、安装Ganache(原来用testrpc):在内存中模拟以太坊运行并对外提供rpc服务。

npm install -g ganache-cli

4、运行ganache-cli

ganache-cli

5、生成一个DApp的项目

mkdir project1

truffle init

如果想用truffle中的某个例子,可以用

truffle unbox pet-shop

“pet-shop”是例子名称

6、编写智能合约

具体如何用solidity编写智能合约可参考各种文章,这里不再重复。

编写好的智能合约的Project1.sol文件放到contracts目录下

7、编译和部署智能合约

在migrations目录下创建文件2_deploy_contracts.js:

var Project1 = artifacts.require("Project1");

module.exports = function(deployer) {
  deployer.deploy(Project1);
};

之后执行:

truffle compile

truffle migrate

如果你的智能合约没有问题的话,现在你的智能合约应该已经部署到你用来测试的ganache中去了。

这里可能遇到的问题是:默认的truffle生成的项目,测试用的ganache的地址和端口会被设置成http://localhost:7545,而实际上执行ganache-cli之后的服务端口是http://localhost:8545,需要在truffle.js中修改一下:

module.exports = {
// See <http://truffleframework.com/docs/advanced/configuration>
// for more about customizing your Truffle configuration!
networks: {
development: {
host: “127.0.0.1”,
port: 7545,   //改成8545
network_id: “*” // Match any network id
}
}
};

8、编写前端的js代码跟以太坊交互

通常需要如下的辅助js库:

<!– jQuery (necessary for Bootstrap’s JavaScript plugins) –>
<script src=”js/jquery.min.js”></script>
<!– Include all compiled plugins (below), or include individual files as needed –>
<script src=”js/bootstrap.min.js”></script>
<script src=”js/web3.min.js”></script>
<script src=”js/truffle-contract.js”></script>
在此基础上,编辑你自己业务逻辑的js,通常命名为app.js,app.js的框架如下:

App = {
web3Provider: null,
contracts: {},

init: function() {

//初始化你自己的页面、变量等

return App.initWeb3();
},

initWeb3: function() {
/*
* 初始化web3:
*/
if (typeof web3 !== ‘undefined’){

//如果你的浏览器安装了MetaMask的钱包插件,那么插件会赋值web3.currentProvider
App.web3Provider = web3.currentProvider;
}
else
{

//如果没装插件,那么创建一个基于Http的provider,这里用到的就是用ganache-cli启动所提供的rpc服务,因为ganache-cli启动的时候绑定的是localhost,所以测试所使用的浏览器也要在本机。(如何让ganache-cli绑定其他地址我还没找到)
App.web3Provider = new Web3.providers.HttpProvider(‘http://localhost:8545’);

}
web3 = new Web3(App.web3Provider);

return App.initContract();
},

initContract: function() {
/*
* 初始化智能合约,实际上就是为你的智能合约创建一个对应的js对象,方便后续调用
*/

//通常的做法是使用你的智能合约编译之后生成的abi的json文件,该文件在用truffle compile之后,生成在build/contracts/目录下,因为我用了一个Division.sol,所以用Division.json,你可以根据你的实际情况来写。
$.getJSON(‘Division.json‘, function(data) {
var DivisionArtifact = data;
App.contracts.Division = TruffleContract(DivisionArtifact);
App.contracts.Division.setProvider(App.web3Provider);
//用智能合约中的信息来更新你的web应用,App.refreshPlots()是我例子中获取智能合约中信息并更新UI的函数

return App.refreshPlots();
});

return App.bindEvents();
},

bindEvents: function() {

/*
* 事件绑定,这个可以根据你的UI来设置,例子中就是绑定一个button的点击操作
*/

$(document).on(‘click’, ‘.btn-adopt’, App.handlePlot);
},

refreshPlots: function(plots, account) {
/*
* 这个函数就是上面initContract中调用的用智能合约更新页面
*/

        //继续使用division这个智能合约做例子
         var divisionInstance;
         App.contracts.Division.deployed().then(function(instance){
                 divisionInstance = instance;
                 //getGenPlots是Division的这个智能合约的一个查询函数(不需要gas),需要3个参数
                 return divisionInstance.getGenPlots(0,0,2);
         }).then(function(results){
                 //注意:这个地方有点意思,我原先理解也有问题,后来打印输出才搞明白
                 //智能合约返回的多个结果变量在这里就是一个results数组
                 //数组的每个成员就是智能合约返回的每个结果变量
                 //以getGenPlots为例,Division.json中定义如下:
                 /*"name": "getGenPlots",
                     "outputs": [
                     {
                         "name": "",
                         "type": "uint64[]"
                     },
                     {
                         "name": "",
                         "type": "address[]"
                     },
                     {
                         "name": "",
                         "type": "uint256[]"
                     },
                     {
                         "name": "",
                         "type": "uint8[]"
                     }
                     ],
                     "payable": false,
                     "stateMutability": "view",
                     "type": "function"
                  */
                  //那么:results[0]是uint64[]
                  //      results[1]是address[]...

                 console.log(results[0].length);
         }).catch(function(err){
                 console.log(err.message);
         });
 },
handlePlot: function(event) {

/*
 * 这个函数就是上面bindEvents中调用的响应函数,演示要花eth的函数调用
 */
    event.preventDefault();
    //从event中获取参数,这是jquery的东西,跟web3无关
    var plotId = parseInt($(event.target).data('id'));

    var divisionInstance;
     //获取以太坊帐号信息
     web3.eth.getAccounts(function(error,accounts){
         if(error)
         {
             console.log(error);
         }
         //我随便取帐号列表里的第3个帐号。
         //因为我们连的是ganache-cli的rpc模拟服务,
         //其中给我们预制了几个有eth的帐号
         //如果安装了MetaMask插件,应该获得的就是MetaMask里的帐号
         var account = accounts[2];
         App.contracts.Division.deployed().then(function(instance){
             divisionInstance = instance;
             //调用智能合约的buyPlot函数,该函数需要2个参数,
             //后面的{}中的内容跟发起以太坊交易的时候所带的默认值。
             //from: 使用哪个以太坊帐号
             //value: 要使用的eth数量,以wei为单位(1eth=10^18wei)
             //gas: 矿工费,以wei为单位
             return divisionInstance.buyPlot(plotId, 3, {from: account, value: 100000000000000000, gas:6000000});
        }).then(function(result){
            //返回结果后重新更新UI
            return App.refreshPlots();
        }).catch(function(error){
            console.log(error.message);
        });
     });
 }

};

测试你的基于Web的DApp是否正常,可以使用nodejs里面提供的lite-server模块来当简单的webserver来用。

安装lite-server,在你的truffle项目目录下,执行:

npm install lite-server

安装完之后会在项目目录下声称node_modules目录,lite-server以及依赖的模块都在该目录下了。

要运行lite-server,还需要编写项目目录下的package.json文件:

{
     "name": "项目名称",
     "version": "1.0.0",
     "description": "",
     "main": "truffle.js",
     "directories": {
         "test": "test"
     },
     "scripts": {
         "dev": "lite-server",
         "test": "echo \"Error: no test specified\" && exit 1"
     },
     "author": "",
     "license": "ISC",
     "devDependencies": {
         "lite-server": "^2.3.0"
     },
     "dependencies": {
         "liteserver": "^0.3.0"
     }
}

还需要编写bs-config.json来配置一下lite-server
{
 "server": {
 "baseDir": ["./src", "./build/contracts"]
 }
}

baseDir是用来设置lite-server所提供的web服务的文件路径的。这个设置表明你可以把你上面写的app.js,依赖的各种js放到./src目录下,然后写index.html,把app.js等集成进去,就大功告成了。

启动lite-server,执行:
npm run dev

不仅启动了lite-server,而且会启动一个浏览器去打开页面。

本文的目的是为了澄清一下写DApp的各项工具之间的架构关系,帮助技术人员更快的理解和实现自己的项目。

具体的例子网上多如牛毛,就不去写业务的具体代码了。


基于HyperLedger的Fabric实现私有链–Doing

一、Fabric的架构

Fabric的架构我觉得下面这张图描述的还是比较清楚的。

Fabric的节点类型主要有Peer和Orderer两类。Peer负责背书(Endorser)、向帐本(区块链,Ledger)提交(Committer)、执行智能合约(Chaincode)、维护帐本(Ledger)。Orderer节点负责对交易进行排序(有人把这个过程叫完成共识)。

其他的MemberShip节点实际上就是个CA(证书中心),负责发证书。Fabric的各节点之间是靠数字证书来实现权限管理和身份认证的。

用户(或者客户端)完成一次调用智能合约的过程如下:

(1)生成一次智能合约调用请求(这里叫Proposal),发送给背书节点(Endorser ,包含在Peer节点上)。

(2)背书节点验证请求的正确性,并且调用智能合约(ChainCode)来模拟执行,生成执行操作过程集合(就是把对数据的读写操作过程和结果记录下来),背书节点对其进行签名(就是开个证明说这次调用的过程和结果是正确的),然后返回给请求发起方。

(3)请求发起方再把背书节点返回的结果发给Orderer节点去进行排序(因为同时会有很多人发起请求,需要有人对其排序,然后才能按顺序写入帐本)。

(4)Orderer节点对请求进行排序后,把排序后的请求发送给Peer节点上的Commiter,Commiter负责把这些交易通过Ledger记录下来。

这样就完成了一次智能合约的调用。

从上述过程来看,Fabric实际上适合应用在小范围内的私有环境或者联盟环境中,不适合公链。

Fabric的智能合约实际上就是一个程序,部署在一个docker中,背书节点在需要时调用它执行。

Fabric用一个数据库(类型可选)来用key-value的方式存储智能合约的数据。

二、Fabric的部署

Fabric的部署十分依赖Docker。要部署Fabric,需要先在机器上装Docker。如何装Docker请自行查找资料。因为每个人用的操作系统和版本都不同,所以安装docker时遇到的问题也可能不同。我遇到的最讨厌的问题就是docker安装完成之后一启动dockerd,就报错:

time=”2018-03-07T11:06:03.573781204+08:00″ level=error msg=”[graphdriver] prior storage driver devicemapper failed: devicemapper: Error running deviceCreate (CreatePool) dm_task_run failed”

最后发现是我的Slackware-Current版本使用的是kernel-huge内核,其中对devicemapper的支持有点问题。有人说使用kernel-generic内核就可以了,我懒得改,最后在/etc/default/docker中加入:

DOCKER_OPTS=”$DOCKER_OPTS -s overlay”

使用overlay模式搞定。

装好Docker之后,

(1)mkdir -p go/src/github.com/hyperledger

(2)cd go/src/github.com/hyperledger

(3)git clone https://github.com/hyperledger/fabric.git

(4)cd go/src/github.com/hyperledger/fabric

(5)make orderer

(6)make peer

(7)make configtxgen

(8)make cryptogen

(9)make configtxlator

(10)make orderer-docker

(11)make peer-docker

(12)make tools-docker

(13)make docker

上述过程会有很多坑,折腾吧。主要都是缺少依赖库引起的。有遇到问题可以google/baidu或者在评论区留言。

如果一切顺利,最后执行docker images,会出现:

这表明你的安装差不多对了。

下面开始运行fabric来测试你的部署吧。

(1)cd go/src/github.com/hyperledger/fabric/examples/e2e_cli

(2)sh network_setup.sh

如果最后看到如下的结果,表明你的部署应该对了:

这是个fabric的例子,用命令行cli的方式来实现部署go语言实现的chaincode_example2,为了帮助对fabric的理解,你可以执行:

docker exec -it cli bash

进入cli的docker,然后在docker里执行:

peer chaincode query -C mychannel -n mycc -c ‘{“Args”:[“query”,”a”]}’

这条操作的目的是在chaincode上执行查询a有多少币。执行结果类似:

我的这个改过了,所以显示query result: 910

如果你还想了解更多如何用cli来部署合约、初始化合约、执行合约(invoke),你可以看一下go/src/github.com/hyperledger/fabric/examples/e2e_cli/scripts/script.sh文件,仔细研究一下它的各个命令。

三、智能合约的实现

实际上,链只解决了智能合约(ChainCode)的管理框架、状态数据的存储框架、帐本的记录框架等基础功能。真正实现链的功能多样化要靠各种智能合约才行。

Fabric 1.0 支持Go/Java开发的智能合约。据说今后要支持Python等语言。

下面我们试图要实现一个消息订阅的智能合约。

1、业务逻辑

(1)消息发布者A可以发布接受订阅的智能合约,表明消息的类别等简要说明以及订阅价格。

(2)消息订阅者B可以支付费用成为A的订阅用户,订阅者B的信息保存在智能合约中

(3)当B想阅读A发布的消息时,A的消息订阅服务从智能合约中查询B是否是消息订阅者,如果是,则允许阅读,如果否,则拒绝阅读。

2、与以太坊的代币的交互

B支付费用使用以太坊发行的代币支付。(如何在ChainCode中与以太坊交互部分还在找资料调研中)

3、实现细节

具体的chaincode会发布到github中。

基于区块链的去中心化的同学录–Thinking

同学录承载了70后、80后的回忆,卖给Sohu的ChinaRen,后来成为人人网的校内网,都是以同学录起家。潮起潮落,当年承诺陪你到永远的这些网站最终都雨打风吹去,那些无处安放的青春记忆该走向何方?

去中心化的区块链+Token似乎能够解决上述问题。数据的分散存储不会因为某个公司的业务裁撤而丢失。Token能让用户按需付费。

人人为我,我为人人,共同存储,共同服务。利用区块链将分散的存储能力统一为可持续发展的服务能力

利用智能合约实现同学关系的认证,利用小程序实现区块链与微信的对接,打通社交的最后一公里。