この記事は Ethereum Advent Calendar 2017 の4日目の記事です。
SolidityでのEthereum DApps開発環境について書きます。
IDE(統合開発環境): IntelliJ IDEA
Ethereumに初めて触るとき、Remix(旧browser-solidity)から入る方は多いでしょう。
しかし習熟としては最適なのですが、実際に業務として腰を据えて開発を行おうとすると色々な面で厳しくなってきます。
私は、Solidityの開発に汎用IDEとして定評のあるIntelliJ IDEAを使用しています。
Solidityプラグイン
IntelliJ にはintellij-solidityというSolidity用プラグインが存在します。
意欲的に開発が進められており、現時点でも実務でSolidity開発を行うための充分な品質を備えています。
デフォルトのカラースキーマでは少々コードを読みづらいので、自分好みに少しいじるとぐっと可読性が上がるのでおすすめです。
IntelliJ IDEAはJetBrains社の製品でそれなりの値段がしますが、私はSolidity開発だけでなくあらゆる開発に同社のIDEを使用しています。安定性・カスタマイズ性が高くよくできており、 お金を払う価値のあるプロダクト だと感じています。
統合テスト: Mist
DAppsの開発において品質の担保は何よりも重要です。
作成するアプリケーションにもよりますが、1つのバグが致命的な損失へ繋がる可能性がWEB開発等に比べて極めて高いからです。
truffle等のフレームワークを使用して開発を行い、デプロイしたコントラクトは必ず手動でテストを行う必要があります。
Geth等のターミナルですべてを完結させてもよいのですが、Ethereum公式DAppsブラウザであるMistを用いてGUIでテストすることも可能です。
GUIには非エンジニアでもテストに参加できるという利点があります。ここではMistを使用する手順を記載します。
Mistの入手
公式から入手します。
必ず最新版を使用し、実際の業務では 更新をウォッチしてすみやかにアップデートを適用する よう心がけてください。
Mistの起動
Mistはデフォルトで裏でgethをfastモードで起動します。
もし既にローカルでgethを使用していたら、先に起動しておけばそちらを使用してくれます(細かいオプションの調整などが可能)。
最初に起動した時は同期にかなり時間がかかるので注意してください(1晩寝かせる必要があるかもしれません)。容量も数十GB〜 必要です。
場合によってはlight clientモードでも良いのかもしれません(ゴリゴリ開発することが可能なのかは未検証)。
light clientモードはうどんさんによる↓のエントリがわかりやすいです。
デプロイされたコントラクトの確認と操作
コントラクトを確認するには アドレス と ABI が必要です。
truffleでビルドした場合の取得方法は以下の通りです。操作はメインネットでもテストネットでもプライベートネットでも変わりません。
アドレス
コントラクトのETHアドレスです。
デプロイ時にターミナルに出力されます。
ABI
ABIはコントラクトを使用する上でのインターフェイスの情報です。
truffleでビルドした場合は、/build/ ディレクトリ以下に生成された対象コントラクトの.jsonファイルの abi キーの値となります。以下の画像の例では赤枠のデータです。
コントラクトの確認と操作
-
Mistのコントラクト画面を開き「コントラクトを見る」をクリック
-
「コントラクトアドレス」に上記で取得したETHアドレス、「コントラクト名」はただのラベルなので適当に、「JSONインターフェイス」にABIをそれぞれ入力して「OK」。
3. コントラクトが一覧に表示されて操作できるようになっていればOK。
操作方法はそう迷うことは無いと思うのですが、いろいろクセはあるので需要があればまた書きます(たぶん)。
補足: Moon Browser
先のDevcon3でMistの後継であるMoon Browserが発表されました。
2018年にリリース予定で、今後MistはこのMoon Browserへ置き換わってゆくものと思われます。
補足: Ganache
truffleの開発チームが新しいEthereum開発環境としてGanacheをリリースしています。
良さそうなので、今後こちらを利用してゆくかもしれません。
統合テスト: プライベートネット
フロントはMistを使うとして、じゃあブロックチェーンは何を使用するのかというと私はプライベートネットを構築して使用しています。
最終的にはメインネットや公式テストネットのRopstenでのテストも必須なのですが、作業効率を考えるとプライベートネットを立てるのが一番です。
ちょうどこのAdventCalendarで昨日 @umidachi さんが良い記事を書いてくださいましたのでご参照ください 
(記事ではラズパイ上ですが私は開発環境のMacに構築しておりました)。
ユニットテスト: ganache-cli(test-rpc)
手作業でのテストはもちろん、自動テストもコントラクトの品質を担保する上では必須です。CIで動かすためにも重要であり、またコントラクト開発時にいちいち手作業でテストしていては非常に効率が悪いのですが自動テストがあればテンポ良く開発が可能です。
検索すれば記事は出てくるので詳細割愛しますが、test-rpc(2017/11にganache-cliに名称変更しました)を使用しています。
CI環境: CircleCI
CircleCI上でtest-rpc(ganache-cli)を使用しています。
参考までに、以下はALISのICO用コントラクトのCI環境です。
備考
- 粒度を細かくすると他にもいろいろあるのですが、量が多いので一旦ざっくりとまとめました。需要があればまた追記or別記事を書きます。
- ブロックチェーン、特にEthereum周りは極端なまでの速度で進化しているのですぐに情報が古くなってしまいます。お気をつけを。
- だからこそ面白いんですが
- だからこそ面白いんですが