Rubotyプラグインを公開していこうかい? ruboty-dajareリリースしました。
ダジャレプラグインつくった。生活に笑いを。
よさそうなサイト
オープンデータのサイトにはいろいろ変なデータがあるので、さくっと何か作るのに向いていそう。
ダジャレ集｜オープンデータ共有＆ダウンロード｜LinkData
まとめ
チャットで勤怠管理するruboty-kintaiをリリースしました
@ruboty 出勤/@ruboty 出勤@8:28, @ruboty 退勤/@ruboty 退勤@16:30で記録、@ruboty 先週から今日までcsvでのようなかんじで勤怠管理する。
きっかけ
前々からつくりたかったのだけどきっかけがなかった。増井さんがなんかつくっていらしたのでかっとなって今日の夕食を食べてからつくった。
だめなところ
- テストない
- やすめない
- 記録を消せない
いいところ
勤怠1ヶ月前から今日までcsvでのような雑な感じで表を出せる(powered bytokiyomi)@ruboty 帰りたいで出社を記録できる
まとめ
働かなければ勤怠管理は必要はない。
Rubotyが静かになるruboty-silentを公開した
たまには静かにしててもらいたいときもある。 でも仕事はしてほしい。
くふう
今までRuboty::Robotに手を加えることはなかった。
これからはRuboty自身のクラスにカジュアルに手を加えていきたい。
こうすればよかった
extendじゃなくてRuboty::Robotに対してModule#prepend使えばよかったかなぁと思っている。
ただ、extendすることによってRuboty::Robot以外のいかなる互換インターフェイスを持ったロボットがきても対応できるようになった。
こういうのできそう
Ruboty::Robotのsayを上書くことで、ログを取るためにロボットをすりかえるアダプタとか、今までにないところにフックを追加するモンキーパッチ天国のプラグインをつくりたくなった。
まとめ
ruboty-seppukuに続いてこれなの、疲れがたまってそう。
Rubotyに切腹を命ずるruboty-seppukuつくった
@ruboty seppukuで死ぬ
くふうしたところ
Herokuでも死ぬ
HEROKU_APP_NAMEとHEROKU_API_KEYをheroku config:setなどで設定しておくとbotプロセスのDynoの数を0にする。
ハマったところ
Dynoの中から自信のアプリ名をとる方法がわからなかった。
自身がHerokuで動いているか否か
Herokuで動いている場合環境変数のDYNOが設定されているようなのでそれを使って判定した。
is_herokuというgemもあるが、あちらはDATABASE_URLが設定されているかどうかを見て判定している。
まとめ
いまわの際のメッセージが思い浮かばなかった。プルリクお待ちしています。
Rubotyが代わりに「ちょっとHerokuの様子みてくる」ruboty-heroku_statusを公開した
Rubotyが代わりにちょっとHerokuの様子みてきてくれる。
くふうしたところ
気持ちのぶん人間らしい受け答えをさせるようにした。
さくっと作れて実用度が高くなるようにした。
Heroku Statusは簡単なjsonのapiなのでRuby標準ライブラリだけで扱える。
ChatOpsを意識
改めてRubotyの記事を読むと次のようなことが書いてあった。 実用度低いもの作っても使わなくてもったいないのでChatOpsに使えそうなものを作った。 作者の意思を尊重。
元々DevOpsのOpsの部分を任せる用途(=ChatOps)で開発をはじめたので、 その辺を便利にするプラグインをつくってBotと仲良くやっていきたいという気持ち。
まとめ
私のRubotyはHerokuで動いてる。 なので「ちょっとHerokuの様子見てくる」までもなくHerokuに何かあるといち早く姿を消す。 予想外に実用度が低いプラグインになったぞ、、、
