IFTTT + Line Bot + Herokuでリマインダーを半自動化した話 ~環境編~

モチベーション

新年早々母親が体調を崩してしばらく家をあけることになってしまい、父親が毎日飲む薬を飲み忘れるという事態が発生しまくりました。

かといってこちらが毎日決まった時間に"薬飲めよ〜〜"っていうのはさすがにきついですよね。 決まった時間に何かするのは人間のやる仕事じゃない。

まぁ決まった時間に一方的にリマインドを送るのは簡単なんですが、きちんと薬を飲んだかはわからないわけです。 Lineで"飲んだ"といえば、きちんと飲んだものだとしても、決まった時間から一定時間が過ぎたのにも関わらずアクションがない場合は人間が"薬飲めよ〜〜"って言う必要がでてきます。

これもある程度ルールがあるわけだから人間より機械の方が得意そうです。

ってなわけでIFTTT + Line Bot + Herokuでリマインダーを半自動化したよという話をします。 今回は環境編で、なんでそのツールを選んだのだとか、どんな言語で開発したのだとかを書いていきます。

ちなみに"半"自動化のアナログの部分は父親のapple watchでボタンを押す動作だけですw

現時点でのプロトタイプ

f:id:cappyzawa:20180126024955p:plain こんな感じでbotだけがしゃべりまくります

ちなみに人間の手で飲んだと報告すると f:id:cappyzawa:20180126025202p:plain

こんな感じでbotが褒めてくれるようにしました

本当はbotでのメッセージを読み取りたかったのですが、botの投稿にはwebhookが飛ばない様になっていてapp側でメッセージが受信できませんでした 残念 簡単に自動応答できる仕組み(とりあえず投稿があったら決まったメッセージを投稿するというやつ)があるからbotの投稿も検知してしまうと無限にメッセージを連鎖させてしまうことを避けるための措置なのかな だったらそれを無効にするようなオプションつけてほしいなぁ

しゃべりすぎました

環境

IFTTT

IFTTT

IFTTT

  • IFTTT
  • 仕事効率化
  • 無料
これです。

これを使う前まではmythingsでアプリだけで半自動化していました

myThings

myThings

  • Yahoo Japan Corp.
  • ユーティリティ
  • 無料

f:id:cappyzawa:20180126030258p:plain

mythingsは簡単にトリガーとアクションを紐づけられて、非エンジニアにも優しいアプリなのですが、それゆえにちょっと難しいことをやるのはできなそうでした。 あとトリガーとして時刻起動がないのはなんでだよって感じw googleカレンダーと連携して無理やり時刻起動みたいなことをしていました。。。

でもそれ以外は使いやすいですよ

さて、IFTTTに戻ります。 IFTTTはトリガーの種類、アクションの種類共にめちゃくちゃ豊富ですね。全部英語ですが。 トリガーとして、時刻での起動があり、アクションとしてLineの投稿もあるので、リマインダーをIFTTT、報告をmythingsにして運用してみました。

f:id:cappyzawa:20180126030459p:plain

報告もIFTTTでいいんじゃって思うかもしれませんが、IFTTTには共有の機能がない(mythingsはある)のでちょっと登録してもらうのが面倒だったのでmythingsを使っていました。

これでいいじゃんと思うかもしれませんが、

まぁ決まった時間に一方的にリマインドを送るのは簡単なんですが、きちんと薬を飲んだかはわからないわけです。 Lineで"飲んだ"といえば、きちんと飲んだものだとしても、決まった時間から一定時間が過ぎたのにも関わらずアクションがない場合は人間が"薬飲めよ〜〜"って言う必要がでてきます。

この問題が解決されません。

これを解決するためには、やはりこちら側でbotを制御する必要がでてくるわけです。

LineBot

リマインダーの投稿先としてLineを選んだのは自明ですが、一番メッセージアプリの中で(報告者側が)開く頻度が多いからです。

今回はgoでAppを開発してるんですが、以下のSDKを利用させてもらいました。

github.com

goは最近触り始めたんですが、書いててなんか楽しいですね ググラビリティが低いのがなんともいえないですが、GoDocがしっかりしてるのでリファレンス読めば大抵解決します。

Heroku

www.heroku.com PaaSです。 業務ではcloudfoundryを使用していますが、今回はherokuを使いました。 利用可能になるまでが早いですし、1Appなら何しても無料(たぶん)なので良いです。

PaaSを使うことによって、こちらはAppの開発をしてればいいだけなのでめっちゃ楽でした。 herokuの環境設定は秒で終わったので何したかも覚えてないです。

PaaSを使うにあたり、困ったことが一点ありまして、

  • Appに状態を持たせないことが望ましい

という点です。PaaSのapp内でファイルをもったりするのはよろしくないということです。

ただ、じゃあDBと接続するかといわれてもそこまでしたくないしどのDB使えばええんやということで今回がっつりルールを無視して環境変数に状態を持たせました。 業務でPaaSの推進をしているわけですが、アンチパターンとしていいのかなと思ってますw

App

  • 言語: go
  • WebFramework: Gin
  • CI: travis
  • CD: Heroku

ざっくりこんな環境ですかね。 goだとWebFrameworkは別に使用しなくてもさらりとかけるのかもしれませんが、なんだかんだWebFramework使った方が簡単にかけますよねw いろいろWebFrameworkはありますが、Ginが一番POSTのBodyを受け取り易そうだと感じたのでGinにしました。

github.com

CIはtravisです。ただ、現時点でテストをかけていないのでCIと呼べるかは怪しいですw 今はdummyのテストが置いてあり一応PRやmaster push時にtravisでテストが走る様になっています。 ただ動作するコードは猿でもかけると思ってるので、テストとかインタフェースとかもっと理解したいなあと思ってます

Travis CI - Test and Deploy Your Code with Confidence

CDはHeroku使ってます。 使ってるというかherokuが勝手にmasterにmergeされたらdeployしてくれます。 本来ならmasterにdeployされたらtravisでテストが走り、成功したらheroku deployが正解だと思うのであとでここは直す必要がありそうです。

おわりに

だらだら書きましたが環境は以上です

次は実装編を書くかも

実装といってもただ動くだけの猿コードですが。。。