30日間で21バージョン、OCAP Playgroundはどう変わったのか？

先月の7月は、私が北京で過ごしたこの10年間で最も暑い月でした。私が担当するOCAP Playgroundは終始急ピッチで開発が進められ、7月だけで21の内部バージョンをリリースし、バージョン番号は 0.7.3 から 0.11.2 まで進みました。この記事をお読みになる頃には、オンライン版のバージョン番号はすでに 0.11.2 を超えている可能性が高いでしょう。

なぜこれほど多くの内部バージョンがあるのでしょうか？バージョンのリリースには時間がかからないのでしょうか？これほど多くの新バージョンを苦もなくリリースできるのは、私たちが非常に速いペースでデリバリーできるからだと胸を張って言えます。Playgroundの各新バージョンは、ビルドから公開まで10分以内で、しかもすべて自動化されています。ArcBlock技術チームがどのようにしてこのデリバリー速度を身につけたのか気になる方は、ArcBlockの技術VPによる記事「数十のRepoを自在に扱うには？」を読んでみてはいかがでしょうか。

前置きはこのくらいにして、以下はGitHubから取得したPlaygroundの直近30日間のコードマージ履歴です（実際にはこのページに収まりきっていません）。

インターネット製品に携わったことのある方は、こう思うかもしれません。1か月にこれほど多くのイテレーションを行うにあたり、いったいいくつの目標を設定したのか、と。OCAPサービス上に構築された最初のアプリケーションであるPlaygroundは、開発者がOCAPサービスに触れる窓口です。すべてのイテレーションは一貫して、開発者がいかに快適に使えるようにするかを軸に進められました。具体的には、次の重要な目標が含まれます。

ArcBlockプロジェクトの進捗を追っている方は、こう尋ねるかもしれません。私も時々Playgroundを開いているけれど、画面にそれほど大きな変化は見当たらない、と。ここからは、これらのイテレーションが実際にどこに反映されているのかを詳しく見ていきます。

改善されたテーブルビュー：Table View

人間が読みやすいデータ表示

改善後のテーブルビューでは、OCAPサービスから返されるデータを可能な限り人間が読みやすい形式に整形します。たとえば、Bitcoinネットワーク上の送金額やアカウント残高はBTC単位で桁区切り付きの数値に、ブロックサイズはKB、MB形式の数値に整形されます。以下の図をご覧ください。

インタラクティブなデータ表示

改善後のテーブルビューでは、アカウントアドレス、トランザクションアドレス、ブロックアドレスを、対応するブロックエクスプローラー（たとえば blockchain.com、etherscan.io）へ移動できるリンクとして整形し、開発者が自分でコピー、貼り付け、検索する手間を省きます。以下の図をご覧ください。

ネストされたデータへの対応

テーブルビューは、単純な行列形式の結果表示だけでなく、多階層にネストされたデータにも対応し、内側のデータをポップアップレイヤーで表示できます。以下の図をご覧ください。

特に大きなテーブル

クエリで返されるデータが多い場合、そのすべてをテーブルビューに収めると非常に窮屈で読みにくくなります。そのような場合は、縮小表示したテーブルで重要なフィールドを優先して表示し、ユーザーがテーブルを展開した後ですべての行と列を表示します。以下の図をご覧ください。

改善されたチャートビュー：Chart View

「文章より表、表より図」という言葉があります。適切なデータ可視化は、データに含まれるパターン、特徴、さらには問題まで一目で捉えられるようにします。そのため私たちも、ブロックチェーンデータをどのように可視化するかの研究に多くの時間を費やしました。以下は、その具体的な進展のうち2つです。

ブロックチェーンの資金フロー可視化：Sankey Diagram

ブロックチェーンネットワークは巨大な価値流通ネットワークであり、価値を運ぶ媒体がトランザクションです。Sankey Diagramはネットワークフローを非常に直感的に可視化できるため、次のような可視化対応を追加しました。

クエリ結果にトランザクションデータが含まれ、そのトランザクションに送信者と受信者が含まれている場合、Playgroundが自動的に検出し、チャートの種類にSankeyのサポートを追加します。たとえば次のクエリです。

{
  transactionsByAddress(sender: "1NSc6zAdG2NGbjPLQwAjAuqjHSoq5KECT7") {
    data {
      blockHash
      blockHeight
      fees
      feesOverWeight
      hash
      index
      total
      lockTime
      numberInputs
      numberOutputs
      size
      strippedSize
      version
      virtualSize
      weight
      witnessHash
      inputs {
        data {
          account
          blockHash
          blockHeight
          index
          txHash
          preOutput
          preTx
          value
          script
          sequence
          scriptType
          txHash
          txIndex
        }
      }
      outputs {
        data {
          account
          blockHash
          blockHeight
          index
          script
          scriptType
          txHash
          txIndex
          value
        }
      }
    }
  }
}

ここだけの話ですが、Sankey Diagramを使っている最中に、可視化を通じてデータのバグを発見し、担当の同僚にフィードバックしました。

ブロック一覧データの可視化：BlockList

実物になぞらえた視覚的な表現も、データをより生き生きとさせ、その特徴を鮮明に浮かび上がらせます。ブロックに詰め込まれているのはトランザクションで、箱のようなものです。それなら、なぜ箱の形でブロックデータを表現しないのでしょうか？

クエリ結果にブロック一覧が含まれている場合、PlaygroundはBlockListチャートへの対応を自動的に追加します。たとえば次のクエリです。

{
  blocksByHeight(fromHeight: 500000) {
    data {
      height
      hash
      total
      size
      transactions {
        data {
          blockHash
          blockHeight
          fees
          feesOverWeight
          hash
          index
          total
          lockTime
          numberInputs
          numberOutputs
          size
          strippedSize
          version
          virtualSize
          weight
          witnessHash
          inputs {
            data {
              account
              blockHash
              blockHeight
              index
              txHash
              preOutput
              preTx
              value
              script
              sequence
              scriptType
              txHash
              txIndex
            }
          }
          outputs {
            data {
              account
              blockHash
              blockHeight
              index
              script
              scriptType
              txHash
              txIndex
              value
            }
          }
        }
      }
    }
  }
}

より高いエンジニアリング品質

製品の使いやすさだけでなく、コード品質や拡張性なども重視しています。これらへの投資には大きな複利効果があるからです。具体的には、次の取り組みを行いました。

主要モジュールへの自動テストの追加

バグ発生率を下げ、イテレーション速度を維持するため、Playgroundの主要コードの大部分にユニットテストを追加しました。コードをマージする際には、すべてのテストに合格することが前提条件となります。現在、リポジトリ全体のブランチカバレッジは 33% に達しています。以下の図をご覧ください。

styled-componentsによるコンポーネントスタイルの管理

フロントエンドプロジェクトが大きくなると、スタイルをどのように管理するかも重要な課題になります。私たちは styled-components を使ってコンポーネントのスタイルを管理し、各フロントエンドコンポーネントの凝集度を高め、アプリケーションの異なる部分のスタイル間における結合度を下げています。現在、コードリポジトリにはグローバルスタイルを除いて独立したスタイルファイルはありません。

sentryによる本番環境のエラー収集

バグのないソフトウェアを書ける人はいません。私たちも例外ではありません。しかし、バグが発生したときにすぐ把握し、最速で修正することは、誰にでもできるわけではありません。私たちは本番環境に sentry を統合してJSエラーを収集しています。ユーザーの利用中に発生したあらゆるエラーが捕捉され、slackを通じて各プロジェクトの担当者に送信され、可能な限り速やかに修正されます。

その他の改善

コードスタイルを維持するため、travis-ciではwarningレベルのスタイル警告も強制的にエラーとし、開発者に修正を求めています。ソフトウェア開発の世界でも割れ窓理論が作用することを、私たちはよく理解しているからです。今日それを無視すれば、いつか手痛いしっぺ返しを受けます。また、チームメンバー間でのコード再利用を促進し、車輪の再発明を減らすため、storybook も統合してリポジトリ内のフロントエンドコンポーネントを管理しています。これにより、新しいメンバーもすぐに使えるコンポーネントを素早く把握できます。

新たな製品の方向性：Playbook

社内での議論の中から、新しい製品形態であるPlaybookが生まれました。これは、ブロックチェーン開発者がOCAPサービス上で行った研究や発見を調査、記録、共有しやすくするものです。現在、Playbookはすでに初期形態ができあがっており、もう少し磨き上げれば近いうちに公開できるでしょう。興味のある方は、私が執筆した「Introduction to OCAP Playbook」をぜひお読みください。読むのが面倒な方は、スクリーンショットだけでもご覧ください。

おわりに

私が「OCAP Playground入門ガイド」で述べたように、現代のシステムの多くはバックエンドが大きく、フロントエンドが小さい構成です。7月全体のOCAPサービスのフロントエンドにおける進展は以上のとおりですが、バックエンドではさらに多くのことを行いました。今後の記事で皆さんにご紹介します。

気がつけば、もう8月です。私たちはこれまでどおり、定めたロードマップに沿って前進し続け、ArcBlockのエコシステム構築に力を尽くします。最近はフロントエンド、バックエンドのエンジニアも多数募集しており、勤務地は北京とシアトルです。ブロックチェーン業界に興味があり、私たちの仕事の進め方に共感してくださる方は、ぜひご連絡ください。求人情報はこちらです。もちろん、私に直接履歴書を送っていただいても構いません（WeChat：feweekly）。