Botkitで消耗した話

Botkitで消耗した話です．

つらい

自分のNode.jsにおけるブロッキングI/O・ノンブロッキングI/Oまわりの知識や理解が追いついてない説も否定はできない…． なんとかして非同期処理の待ち合わせとかJavaのCountDownLatch的なアレを実装しようかとも考えたけど，スマートさに欠けるか〜と思って諦めた．

storageまわりは非同期APIしか用意してないのに、その他ユーザ定義メソッドとかは全部同期処理を要求してくるの控え目に言って意味不明
誰もその矛盾に気付かなかったのかな

— Convolutional layer (@izumin5210) June 28, 2016

Storageまわりをasync/awaitでラップしたらなんとかなるかと思って試したけど，hearsやmiddlewareの呼び出し元は「falseかそうじゃないか」しか見てないので無意味だった．

ハックしづらい

Botkitにhubot-aliasとhelp機能を実装しようとしたけど，実装のヤバさからそもそも実現するのが厳しいという説が出てきてる
ほんとにここまで作ったやつを全部Hubotに移植したほうが早い気がしてきた

— Convolutional layer (@izumin5210) June 28, 2016

「helpがつくれない」の根拠としては，hearsに渡すkeyword/patternがその関数内に閉じ込められてる（何らかのデータ構造に格納等はしていない）こと．利用者側に特定のmiddlewareを強制するとかならできなくはないが，helpとか意識せず勝手に生成されてほしいですよね．

そもそも

最初はhearsやmiddlewareが非同期処理を許容できるように改造しようかと思ったけど，PRとかIssueがめっちゃ放置されてるのを見てやる気無くしてしまった．

botkit，あまりにもつらいのでforkしてContributeするぞ！と思ったけど，かなりコアなところから厳しい感じなので見捨てて自作するかおとなしくHubotかRubotyつかったほうがよさそうだという結論
そもそもかなりの件数のIssueやPRが放置されてるし死んだっぽい

— Convolutional layer (@izumin5210) June 28, 2016

まとめ

自分にもうちょいやる気と技術力あるならなんとかできるかな〜と思ったんだけど，そもそもPRとか放置されるなら無理だなと． そもそもの問題として，BotkitはHubotやRubotyほどpluggableに作られてるわけじゃない（目的が違う）のかな？

BotkitつかえばつかうほどRubotyってきれいに設計されてたんだなあと感心する

— Convolutional layer (@izumin5210) June 25, 2016

WEB+DB PRESS Vol.82

Slack入門 [ChatOpsによるチーム開発の効率化]