どくぴーの備忘録

真面目なことを書こうとするクソメガネのブログ。いつ投げ捨てられるのかは不明

頑張って作ったアプリがクソの域を出なかった話 #MA_2017

まずはじめに

この記事は クソアプリ Advent Calendar 2017 11日目の記事です。

一日遅刻しています。土下座モン。

作ったものの話をしよう

今年もMashup Awards真っ只中の冬でございます。MAというとハッカソンって言う人もめちゃくちゃいますがその本質は50以上の作品がひたすらプレゼンを繰り返す2nd stage(日曜にありました)に詰まっている気がします。この楽しみを「参加者として」楽しむために目指している人もいるんだろうなーと思っています。

僕はスタッフをしていました。カメラマンです。

そんなMAに僕が今年何を放ったか、そしてどうしてクソのまま終わったのか、どうやってクソから抜け出していこうかという話をしようと思います。

今年作ったもの

hacklog.jp

そう、今年僕は「課題解決」をしようと思いました。

LTイベントやMAのようなプレゼン大会で欠かせないのは「運営としてのTwitter実況」。その中でも僕が目をつけたのは「発表一回目のツイート」でした。

このツイート、僕は本当に大事だと思っていてハッシュタグウォッチしながら参加している人には今誰がどんな内容で登壇しているのかを伝える役割があり。更にはイベント後にtogetterにまとめるようなときにも区切りとしての役割を果たします。

ではその最初のツイート、どうやって投稿しているか考えてみましょう。

  1. 事前の発表リストを用意する
  2. ツイート内容を構成する
  3. 発表者の手番が来たらそれをTwitterの投稿フォームにコピペして投稿

1はしょうがないとして、2、3はかなり面倒です。ツイート内容の構成では決まったテンプレに収まるように与えられたデータを配置する必要があり、3に至ってはコピペなんかしていては発表が始まってスライドが2枚流れてしまう、なんて言ったことだってあります。

僕はそれを解決したくてこのとうだんくんを作る決意をしました。MAの締め切り3日前に。

どんな感じのものなの

f:id:e10dokup:20171211235853p:plain

Hacklogからサルベージした画像がくっそでかい。

こんな感じで登録したイベントの登壇タイトルを選んで開始時にワンボタンでSNS通知できるっていうそれだけのアプリです。なんで一回選ぶの?っていう疑問も持ったのですが、こういうイベントあるあるとして「直前に何らかの事情で発表順が前後する」という話があるのであえて一旦自分の・今から始まる発表を選択するというアクションを要求するようにしました。 イベントや登壇内容の登録はCSVでバルクアップロードできるように後々改良しましたが、基本的にはイベントに紐つけたIFTTTのWebhookに対してリクエストを飛ばしてそこから自作のレシピに応じてアクションを起こすのでIFTTTが許す範囲とWebhookで扱える変数3つの中であればなんでもできるようになっています。

f:id:e10dokup:20171211235753p:plain

実際の構成はこんな感じで、スマホからはデータ登録が(個人的に)めんどくさいので一切その手のことは扱わず、スマホからサーバへの通信はすべてGETリクエストです。ということは登録はWebアプリ化しないといけなかったのですがCSS力とJS力とHTML力が生まれたての赤子未満なレベルのためMaterial Design Lightを使ってもまともに作れていないやっつけ具合で用意しました。サーバはちょっとだけ見に覚えのあったGolangをgin/gormの構成で雑にGAEにデプロイしています。この辺の話は後々の Mashup Award Advent Calendar で書こうと思います。

こんな小規模なのですが、Androidアプリは当時は拡張する気まんまんで作っていたので多少設計しました。と言っても大げさなものを用意してもアレなのでRxJava2/DataBindingでMVVMな構成をとってKotlinで実装しました。KotlinかわいいよKotlin

何がクソだったのか

ここから反省会フェイズです。端的に三点反省していきましょう。

iOS版がない

ないです。持ってないですしおすし…。 こういうものを作って人に見せると日本って残念ながらiPhoneが圧倒的マジョリティなのでiOS版つくらないんです?」とか言われてしまいます。ぐやじい

ニーズに応えきれない

IFTTT-Webhookで変数3つ使えるじゃん!とか考えてしまったのが運の尽きでした。実際運用してみると思っていたよりも初回ツイートテンプレって柔軟性が高くて、発表順が必要なケースがあったり、文字数オーバーに応じてちょちょいと内容を修正できるようにしてあげられるような仕様にして上げる必要があったりと、IFTTTに投げてドゥン!みたいな銀の弾丸的思考は通用しませんでした。

そもそも自分以外セッティング不能

これが最悪。デザインセンスも思ったものを形にするWebフロント知識もないので、出来上がったWebフロントは使いにくく、作った自分くらいしかデータのセットアップが出来ない代物になってしまいました。時間をかければできたんじゃね?と言われれば勉強込みで出来た気もしますが、結果論では他人が気兼ねなく使えるような状態ではないので残念すぎました。

クソから抜け出すために

でもせっかくクソとはいえある程度形にして自分だけでも楽に使えるようにしたいってのが本音なので、これからも作っていこうと思います。というか作っていって自分で使いたいんです。とりあえず次のことを今は考えています。

Web APIの抜本的作り直し

上がったニーズに応えようとすると、IFTTTのWebhookを使うのはともかくとして、サービス側にテンプレを持っている必要があるという結論にしかなりませんでした。そうじゃないと文字数チェックも出来ないし、3つ以上のパラメータに対応できないし…。

ただIFTTT自体はクソ便利なので、最終的にIFTTTに投げるという格好はしばらく変わらないと思います。

ちゃんとWebフロントの勉強をする

少なくとも僕以外の人がまともに使えるものを作れるように勉強します。というか時間をかけます。従いましては誰かおすすめの本を教えてください。

iOS版を作る

モバイル端末に関してはどうもApple端末が気に食わなかったのですが、ついにこの間買いました。知り合いに譲ってもらったiPhone 6sです。 とりあえず早速使いだしていますが今は先月買ったポータブルアンプのPHA-1Aが接続できることに歓喜しておりほぼ開発に使っていないという有様です。さっさとこっちも勉強しろ。

多分Androidと似たような構成でMVVMにやっていく気がしています。AutoLayoutむずかちい。AutoLayoutを1時間くらいいじった後にAndroidのConstraintsLayoutのエディタを触るとなんかめっちゃ快適に思えてすごく楽しくなってくるのでおすすめです。

まとめ

とりあえず本当に思うことは「急ごしらえするんじゃなくて一旦自分でも身近な人にでも一度使ってもらって何かしらのフィードバックを得るべき」ということでした。ワイワイ作って勢いで作り上げるハッカソン的開発メソッドはテンションがハイのまま一段落つくまで持っていけるのですが、出来たものがどうなるのかというのはやってるうちはやっぱわからないので頭を冷やして出来たものを見る時間が必要だと思いました。ですがクソでも作り上げていかないと何も始まらないので一気にやってよかったなって思います。

多分来年のMAにはもっとまともな姿に生まれ変わっていると思います。みんなもクソアプリ、やっていこうな。