NEM Global Hackathon、無事に走り終えることが出来ました！

提出作品

157エントリーから最終選考に残ったのが33アイデア、そのうち提出したチームは12チームと、完走するだけでもなかなか大変だったと思います。
仕事や学校がある仲、ハッカソンに向けてアプリを作るのは大変なのでしょう。私もオフの大阪観光やスプラトゥーン、1月中のジム活動を諦める羽目になりました。
開発している中で得られた反省点や雑多なノウハウがあるのでそれらを共有できればと思います。

目標を達成できたか？

目標は完走、つまり致命的なバグなく動くものを出すことだったので、それについては非常に満足しています！
仕事じゃないから金にもならない（流石に賞金は当てにしていない）、ただ自分の興味に従って開発をすすめるのは、辛い部分も多かったですが、それ以上に得るものは多かったです。
技術面で習得したことについては後にまとめています。
完走したのが、精神的充実と次もやれるぞという気力につながりますね！

新たに習得した技術

Flask

PythonのWebアプリ用フレームワークを使った開発経験を詰むことが出来ました。
Djangoと比べるとシンプルさに分があるフレームワークなので、今回の短期開発で新しく学ぶには適していたと思います。
今までは自分一人でやる場合はR Shinyなどを採用することが多かったですが、pythonでやれたほうが自由度が高いので今後はpython web app開発を中心にやっていきたいと思います。

フロント

HTMLとかCSSとか、自分でいじるのは初めてだったので良い経験になりました。
本当に第一歩からのスタートで、CSSやjavascriptを読み込む位置とか、まさに基本のキを学んだといっていいでしょう。
0と1とでは大きく違うので、この1は自分にとってとても助かります。

NEM

当然習熟度は上がりました。
APIでやれることやれないことを知り、ハマリやすいポイントを体感できました。

反省点

デザインにこだわらなかった

デザインはもともと得意でないし、自分がここに能力を割り振ったところでエッジになるとは思えないです。
それにしてももう少しやりようはあったんじゃないかと思います。テンプレートを当てるとか。
一番いいのは、デザイナーと一緒にやることですが、今回は仕方ないでしょう。
こういうケースでは全部自分でやらずデザイナーを探すべきだということがわかっただけでもいい気がします。

フロント実装への考えが甘かった

バグさえ入り込まなければあまり大事ではないと考えていたのですが、その考えは間違いでした。
ここの実装の良し悪しはアプリケーションの操作感に直結します。
考え方のテンプレートみたいなのがなかったので、何を実装するのがベストなのか分からなかったり、難易度の都合で諦めてしまうことも多かったです。
また、経験がない中での実装だったので原因が明らかでない謎のバグなどに苦しめられ時間をとられてしまいました。

機能によってやる気の差が激しかった

今回作ったアプリケーションは有給をモザイクに置き換えてやりとりをします。
言ってしまえば、大事なのはアイデアで実装は好き勝手やってくれ、という考えなんですね。
私でないと開発できないものではないし、会社ごとに考え方や事情があるでしょうから、全ての会社に対して同じアプリを提供するという訳にはいかないと思います。
モザイクを受信したことをトリガーにあらゆるスクリプトを呼び出せるので現行のソリューションとも親和性があるよ！という主張をしていたのですが、「あらゆる」ものについては別に会社ごとの事情でやってくれというのが本音です。
しかしながら、ハッカソン向けには何か動くものを作らないといけないわけです。
非常にシンプルなアイデアとして

  • 有給受信時、同僚に通知を送る
  • スケジュールをアップデートする

などを考え、後者を採用してGoogleカレンダーを更新するようにしました。
ただここは根幹じゃないので全然やる気が起きない上に、Google APIの仕様に苦しむなど、開発全体のボトルネックになってしまったと思います。
ここについて考える時間を設けて、もっと面白い内容を思いつければ良かったなと思います。

良かった所

NEM APIを触る経験ができた

NEMは確かにAPIを使ってブロックチェーンに触れることができるので他よりも圧倒的に楽で簡単・・・ではあるのですが、経験の有無は非常に大事です。
API Documentが若干不親切な中、あまり参考になるブログ記事などもない中でやらなければならなかったので詰まるところがないわけではありませんでした。
しかし今回経験したこともあり次以降はより効率よくできるはずです。
また、ブロックチェーンアプリにありがちな秘密鍵の保存をどうするべきかとか、ユーザー認証をどうするとか、実際に直面する問題について考える機会を持てたのは良かったです。
秘密鍵をうまく個人が守りながら使いやすいアプリケーションに落とし込むのは相当に難易度が高く感じました。
結局銀の弾丸になるような案は思いつかず、今回の実装ではスコープ外だろうということで秘密鍵や認証についてはスキップしました。
他に気づいたこととしてはNEM APIを触るプログラミングはJSONを解析することが非常に多いので、コードを書いているとJSON疲れが発生しました。
これにはわりと苦しめられることになり、pandas.dataframeへの落とし込みをする関数を作成したときにはかなりの充実感がありました。

βテストをちゃんとやった

短い時間でしたが、ユーザーテストをやってありがたいことにフィードバックまでいただきました。
UI面では独りよがりな実装になってしまっていたので、気づいて対応を考えられたのは良かったです。

次回やるならこういう工夫をする

テスト環境の構築

トランザクション数での境界値テスト

私のアプリケーションでは、アドレスのトランザクションデータを全て取得してその中身について分析をするという処理が有ります。
一方でAPIを触った人なら誰もがマジカヨと思ったであろう、「最新25件のデータしか一回のREQUESTで取得できない」という制約もあります。
これを解決するには、基本的には25件ずつ遡って取得していくしかないです。
(100件引っ張ってくる裏技は教えてもらいましたが、結局25件ずつやってバグがないことを確認してそのままにしています。)
なお、今回はブロックチェーンから毎回データを引っ張ってきているということを明示的にやりたかったため、途中経過をどこかに保存しておくことはしませんでした。

ただ、この処理は行き当たりばったりで実装していると結構複雑になりがちです。
そして複雑になり方は要件によって変わってくると思います。
いつまで遡るか決めたかったり、XEMとモザイクのトランスファーを分けたかったり、安易に一つの処理で色々やろうとするとドツボにはまりかねないポイントがあります。（ハマりました）（ソースめちゃくちゃになってるはず）
また何のトランザクションも発行されていないアドレスが指定されたらどうする？とか、考えなきゃいけないことは、初めに想定した以上のものでした。

今回はなんとかなったのですが、より効率的にやるにはきちんと境界値分析のようなことをやるべきだと思いました。
非常に簡単に言えば、

  • 0件のトランザクション履歴を持ったアドレス
  • 1件のトランザクション履歴を持ったアドレス
  • 24件のトランザクション履歴を持ったアドレス
  • 25件のトランザクション履歴を持ったアドレス
  • 26件のトランザクション履歴を持ったアドレス

は最低限揃えておくべきでした。
実装の仕方ややりたいことによってはより多くのケースを揃える必要があると思います。
APIの練習がてらこの用途のアドレスを作ってみることをおすすめします。

自分の環境のNISを使う場合は、25件の制限を撤廃してくれるといちいちソフトウェア側で実装しなくて楽なので、そういうオプションができれば今後助かりますね。

データを扱いやすい形へ

私のアプリケーションではたくさんのトランザクションデータを集計する機能が必要でした。
それにはJSONではなくdata.frameなどの形式に変換するほうが私にとっては扱いやすいです。
今後もブロックチェーン上の情報のデータ集計をやる羽目になりそうなので、取得した情報をdata.frameなど扱いやすい形へと変換するライブラリを作成するのは非常に有意義かなと考えています。

データビジュアライゼーションの充実

単純に、自分の得意分野をもっと発揮したかったという思いです。
どこぞのAPIを叩いてサービスを作るというよりは、やはりグラフ描画とかデータ処理とかのほうが得意で楽しいのですが、今回はあまりそこに力を入れられなかったのが残念でした。

今後の活動方針

NEM Harvesting Monitorをいよいよ本格稼働させたいです！
まずは日々のデータを自動で更新して、その後にはリアルタイム化とか分析とかやってみたいことが色々あります。
鯖代は1年分以上支援を頂いたのでひとまずは大丈夫ですが、赤字でも良いので広告などで収入を得ることで個人事業主活動の糧にしたいなと考えています。
できればXEM払いで収入を得たいのでもし興味がある方はご一報ください。
今後共、オフの時間を活用しての活動になりますがよろしくお願いします！