今回は、go-ethereumのv1.10から追加されたコマンドである、`go-ethereum snapshot prune-state`を試してみたのでその結果を共有する記事となる。
このコマンドは、go-ethereumのfull nodeを維持すると溜まっていってしまうstate trieのゴミデータを削除（枝切り）するためのコマンドである。つまり、言い換えるとgo-ethereumで肥大化していくストレージの容量を削減することができる。
より詳細な情報については公式ブログを参照。
blog.ethereum.org
前回の続きとして、今回は特にReceiptsの取得処理周りを見ていく。Receiptの取得処理はfast syncの時に呼ばれ、full syncでは呼ばれないというコメントがあるが、そこの動きがよくわかっていないので、該当コードがどうなっているかを解析する。
Ethereumのfull/fast/snap syncの違いについてより詳しく調べいたと思い、gethのソースを読み始めた。
が、なかなかにボリュームがあるのと、同期処理についてかなり複雑だったので、頭の整理のために解析中の内容をメモとして残しておく。
つい最近、社内ハッカソンでGraphQLのライブラリである、ApolloのApollo Client(React版)を触ってみた。その時に、公式のGetting Startedを動かすのに少し手間取ったので、ここに手順をまとめておく。
最後に、GraphQLを触ってみたときの所感を簡単にまとめる。
公式のGetting Startedの記事は以下を参照。
www.apollographql.com
つい最近、社内ハッカソンでFlutterを用いたアプリ開発を行いました。その時に、FlutterやReactなどにおける、State ManagementやApplication Architecture(というか設計手法？)について色々と議論しました。
その中で、Flutterでよく使われているBlocパターンと、自分が昔経験したReactive MVVMが非常に似ており、Blocパターンが採用しているStreamを用いたState管理について良さを説明してくださいといわれたけど、うまく説明できませんでした。
ということで、今回の記事ではStreamを用いたstate管理の利点をまとめたいと思います。
Truffleでちょっと特殊（？）なテストを書こうとしたら思ったよりもハマってしまったので、備忘録的に残しておきます。