shokai印象としてそんな感じがする。だいたいプルリクする時って、バグを見つけて直すのはすぐできるんだけど、自分の修正が何か別のところで副作用を起こしているかもしれない、という不安があってグダグダ色々検証したり他の部分のコードも一応読んだりする時間の方が長いと思う。いう時にとりあえずテスト通っていれば、テスト書いたリポジトリ主がokしているような気になってくるから、すぐプルリク出せる。testとかコマンド一発実行すればテストが走るようにしておいてくれるとプルリクしやすくてうれしい。CIとかでプルリク自体にテスト通過しましたバッジがついていると安心感がある。テストの書き方色々ある去年からnode.js使い始めて、色々作ってるんだけどテストの書き方色々ある気がするのでメモしておく。具体的な書き方は各リポジトリの中見ればわかる。テストが書きにくいものは内部ライブラリのテスト書くUIとか画像処理のテストとか書きにくい。scriptのテストの書き方がよくわからない。robot.respondとか、ユーザーの入力にフックしてるようなのの書き方がドキュメントどこ探しても見つからなかった。scriptと別ファイルに作っておいて、mochaでテスト書いた。scriptの方はテスト書いてない。testから実行できるようにしている。package.jsonのscriptsにコマンドが書けるので便利。testが走るようになる。npmのテストでは、毎回gyazoに画像をアップロードしてリスト取得して削除している。encryptしてtokenを保存している。envこれを実行すると.travis.ymlに環境変数を暗号化して保存できる。Variablesローカルで実行する時は普通に環境変数でtokenを渡せばtest実行できる。testサーバーでtest実行できない時は、lintだけでもかけておくというかlintは設定するコスト低いので全てのプロジェクトでかけるようにはしている。CIでテスト実行できない。しょうがないので、testは手元でやるとして、CIではcoffee-lintだけかけておく。coffeeはわりと文法間違える人いるのでlintだけでもあるとなんか安心感が違う。CIではビルド失敗するので、devDependenciesだけワンライナーでインストールするようにした。lintだけが実行される。–devしたらdevDependenciesだけインストールできそうだったんだけど、依存解決が無限ループして20分ぐらいインストールし続けて終了するのでやめた。gemなんかがそうで、nodeで立てたsocket.ioサーバーにrubyで接続して通信できるかテストをしている。.travis.ymlでメイン言語をrubyにして、それとは別にnodeのバージョン指定をするとrubyもnodeもインストールされる。notifications.slackで.travis.ymlに通知設定が保存される。CI終わったらslackに通知が来る。その他あとは、READMEにサンプルコードの実行方法を書いておいたり、基本的な機能がすぐ試せる実行コマンドを付けておくとissueとかのトラブルシュートに役立つ。なんかきかれたら「〜〜を実行できる?」とか質問しやすい。coffee-lintで1行の文字数が最大80文字という設定がデフォルトになってるけど、80文字というのは昔のパンチカードの文字数が80文字だったからMacとかのターミナルの横幅もデフォルト80文字になって未だに引きずっている意味のない数値らしいので、80文字にこだわる必要はない。長いURL文字列を作る時とかに書きにくくなる。coffee-lintでは0を指定すると制限解除できる。shokai1ヶ月ぐらい前だけどhubotからgithubにissueを建てるのを作った。チャットからissueのリストを見たり作ったりできるので手軽。なんか雑用を思いついたらToDoというリポジトリにissue立てるみたいな運用されてる。apiを使う場合、githubotというnpmが便利だった。githubotはbranchのリストを取る便利メソッドとかはあるけど、基本的にGitHubのAPIをgithubot.get(url,data,callback)とgithubot.post(url,data,callback)で直接扱う。1.0.0-beta2を使っている。tokenをもらって、herokuに環境変数セットする。HUBOT_GITHUB_TOKEN=a1b2cdef3456なおissueはtokenを作ったユーザー名で建てられるようになる。APIをgithubotのpostに渡すだけでissueが作れた。githubのAPIが綺麗に規則的にできているので、githubotもよくあるかっちりしたAPIラッパーである必要がなく、tokenとかパラメータの渡し方の部分だけよしなにやってくれる薄いライブラリになっている。なんか下手にAPIリクエスト先のpathを規則的にメソッド名に変換しているとか、そういうのじゃなくてURLをそのまま書く方がわかりやすい感じがする。APIとライブラリ両方のドキュメントを突き合わせて読まずに済むのはよい。tagとかhttps://github.com/irkit/device/compare/v1.3.5...v2.0.1とても便利だけどプルリク画面からしか見れない、表から辿りつけない画面な気がする。shokai動作を説明するのが楽。githubはmarkdown内で普通にimgタグ使えるのでgif貼っていくといいと思います。gyazoの画像をそのままblogなどに貼ると、アクセスが集中した場合に画像が埋め込めなくされる事があった時期もあったけど(今はないらしい)、githubは自動的にimgタグをCDNにコピーして配信してくれるので安心です。(見る人が少ない社内gitlabとかも問題ないと思う)README.mdとかにgif貼るのもわかりやすくていいですね。shokai連続してgithub上で活動しているとstreakが累計される。別にお金がもらえるとかではなく、ただこれだけ活動していますよという指標なだけ。40日ぐらいを超えたあたりから、なんだか途切れさせたくなくなる。日々ちまちまとしたメンテをしていると途切れにくい。commitする習慣が無いので途切れてしまう。ちなみに日本では16時を境に次の日になる。