首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

30天21 个版本 OCAP Playground 都经历了哪些变化?

6月30日,“开放链访问协议实验台(OCAP Playground)”正式亮相,但这意味着新的开始:一个月之内,OCAP Playground发布了21个内部版本。

为什么会发布这么多内部版本?究竟是怎么做到的?整整30天迭代更新出怎样的产品?全盘负责OCAP Playground开发、ArcBlock 前端架构师王仕军亲撰本文,为你揭秘。

刚刚过去的七月是我十年来在北京度过的最热的月份,我负责的 OCAP Playground 始终处于紧锣密鼓的开发当中,整个七月发布了 21 个内部版本,版本号从 到 ,你看到这篇文章的时候,线上的版本号很可能已经大于 了。

不多废话,下面是截图自 GitHub 的 Playground 近 30 天代码合并记录(实际上这页没放下):

做过互联网产品的同学可能会嘀咕:单月这么多次迭代,到底定了几个目标?Playground 作为架构在 OCAP 服务上的首款应用,是开发者接触 OCAP 服务的窗口,所有的迭代始终围绕如何让开发者用起来爽进行,具体来说包括下面几个关键目标:

方便开发者快速输入查询、执行查询

方便开发者直观的浏览查询结果,最好能从中有所发现或者受到启发

把更多 OCAP 服务的能力暴露出来

方便后续迭代、扩展,保障高代码质量

关注 ArcBlock 项目进展的同学可能会问:我也时不时打开 Playground,没发现界面上有太大的变化啊?接下来我们来扒一扒到底这些迭代都提现在什么地方。

改进的表格视图:Table View

人类可读的数据展示

改进后的表格视图会尽可能的把 OCAP 服务返回的数据格式化成人类可读的格式,比如比特币网络上的转账金额、账户余额,会格式化成 BTC 为单位并带上千位分隔符的数字,而区块大小则格式化成 KB、MB 格式的数字,如下图:

可交互的数据展示

改进后的表格视图会把账户地址、交易地址、区块地址格式化成能够跳转到区块浏览器对应地址的链接(比如 blockchain.com、etherscan.io),节省开发者自己复制、粘贴和查找的步骤,如下图:

嵌套数据的支持

表格视图不仅仅能支持简单行列式的结果展示,也能支持多层嵌套的数据,内层数据通过浮层展示,如下图:

特别大的表格

当查询回来的数据比较多,全部放在表格视图里面,会拥挤不堪,可读性极差,遇到这种情况,我们会优先展示重要的字段在略缩表格中,在用户展开表格之后展示所有的行列,如下图:

改进的图表视图:Chart View

有句话叫“文不如表、表不如图”,恰当的数据可视化能让人一眼瞥见数据中的模式、特征甚至是问题,所以我们也花了比较多的时间来研究怎么做区块链数据的可视化,下面是两个具体的进展。

区块链资金流可视化:Sankey Diagram

区块链网络就是张巨大的价值流动网络,价值流动的载体就是交易,而 Sankey Diagram 在可视化网络流时非常直观,于是有了下面的可视化支持:

如果查询结果中包含交易数据,并且交易里面包含了发送方、接收方,Playground 会自动探测到,并在图表类型种增加 Sankey 支持,比如下面的查询:

我还想偷偷的告诉你,就在使用 Sankey Diagram 的过程中,我通过可视化发现了数据上的 bug,并反馈给了负责的同事。

区块列表数据可视化:BlockList

拟物化、形象化也能让数据更加鲜活,让数据特征跃然纸上,区块里面打包的是交易,就像个盒子,那为什么不以盒子的形态来呈现区块数据呢?

如果查询结果中包含了区块列表,Playground 会自动增加 BlockList 图表的支持,比如下面的查询:

更高的工程质量

在产品易用性之外,我们也很关注代码质量、扩展性等,因为在这些方面的投入具很大的复利效应,具体来说我们做了下面这些事情:

为关键模块增加自动化测试

为了减少 bug 率和保证迭代速度,我们给 Playground 中的大部分关键代码增加了单元测试,每次代码合并会以所有测试通过为前置条件,目前整个仓库的分支覆盖率达到了33%,如下图:

使用 styled-components 管理组件样式

前端项目如何管理样式在项目变大时也会成为比较重要的问题,我们使用 styled-components 来管理组件的样式,保证每个前端组件的高内聚,降低应用不同部分样式之间的耦合性,现在代码仓库中除了全局样式外,没有单独的样式文件。

使用 sentry 收集线上报错

没有人能写出没有 bug 的软件,我们也不例外,但是出了 bug 第一时间知道并最快修复并不是所有人都能做到,我们在线上环境集成了 sentry 来收集 JS 错误,任何用户使用过程中的错误都会被捕捉下来,通过 slack 发送给每个项目的负责人,并以尽可能快的速度修复。

其他改进

为了保证代码风格,我们会强制 travis-ci 对 warning 级别的风格提示直接报错,强制开发者修改,因为我们深知破窗效应在软件开发领域同样起作用,今天你忽略它,总有一天他会回来狠狠的要你一口;为了在团队成员间提高代码复用度,减少重复造轮子,我们还集成了 storybook 来管理仓库中的前端组件,方便新人快速了解仓库中有哪些立马可用的组件。

新产品方向:Playbook

在我们内部讨论过程中,产生了一个新的产品形态:Playbook,方便区块链开发者研究、记录、分享自己在 OCAP 服务上所做的研究、发现,目前 Playbook 已经开发除了雏形,相信不久之后,我们再打磨打磨即可对外公布,感兴趣的同学欢迎阅读我编写的:《Introduction to OCAP Playbook》,不想去阅读的也可以看看截图:

结语

正如我在《OCAP Playground 入门指南》中所讲,现代系统大都是大后端小前端,整个七月 OCAP 服务前端进展如上,那么后端所做的事情就更多了,后续会有文章跟大家介绍。

转眼,八月已经来了,我们会一如既往的在既定的路线图上继续前行,为建设 ArcBlock 的生态而努力。我们最近还在大量招前端、后端工程师,北京和西雅图都要,如果你对区块链行业感兴趣,欣赏我们做事的方式,欢迎来撩,职位介绍见这里,当然,你也可以直接把简历给我(微信:feweekly)。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180810B0YCWM00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券