橋本商会

印象としてそんな感じがする。

だいたいプルリクする時って、バグを見つけて直すのはすぐできるんだけど、自分の修正が何か別のところで副作用を起こしているかもしれない、という不安があってグダグダ色々検証したり他の部分のコードも一応読んだりする時間の方が長いと思う。
そういう時にとりあえずテスト通っていれば、テスト書いたリポジトリ主がokしているような気になってくるから、すぐプルリク出せる。

なるべくrake testとかnpm testとかコマンド一発実行すればテストが走るようにしておいてくれるとプルリクしやすくてうれしい。

プルリク受け入れる側も、Travis CIとかでプルリク自体にテスト通過しましたバッジがついていると安心感がある。

テストの書き方色々ある

去年からnode.js使い始めて、色々作ってるんだけどテストの書き方色々ある気がするのでメモしておく。
具体的な書き方は各リポジトリの中見ればわかる。

テストが書きにくいものは内部ライブラリのテスト書く

UIとか画像処理のテストとか書きにくい。
あとhubot scriptのテストの書き方がよくわからない。robot.respondとか、ユーザーの入力にフックしてるようなのの書き方がドキュメントどこ探しても見つからなかった。

hubot-rss-readerの場合、rss-checkerという内部ライブラリをhubot scriptと別ファイルに作っておいて、mochaでテスト書いた。hubot scriptの方はテスト書いてない。
それをgrunt-simplemochaで実行できるようにして、さらにgrunt testをnpm testから実行できるようにしている。package.jsonのscriptsにコマンドが書けるので便利。

{

  "name": "hubot-rss-reader",

  "private": false,

  "version": "0.6.5",

  "description": "Hubot RSS Reader",

  "main": "scripts/hubot-rss-reader.coffee",

  "scripts": {

    "test": "grunt test"  (注:これがnpm testで実行できる)

  },

(略)

.travis.ymlを置いて、GitHubからTravis CIへのフックを設定すればgit pushしたりプルリク受けたりするだけでTravis CI上でnpm testが走るようになる。

アカウント情報を暗号化してTravis CIに保存できる

gyazo-api npmのテストでは、毎回gyazoに画像をアップロードしてリスト取得して削除している。
oauthのaccess tokenが必要なので、travis encryptしてtokenを保存している。

% travis encrypt GYAZO_TOKEN=a1b2cde --add env

これを実行すると.travis.ymlに環境変数を暗号化して保存できる。

language: node_js

node_js:

  - '0.10'

env:

  secure: asdfadajowejfoaiwejfoawiejfpaiup(暗号化されたtoken)

Travis CI: Environment Variables


ローカルで実行する時は普通に環境変数でtokenを渡せばtest実行できる。

% GYAZO_TOKEN=a1b2cdef npm test

サーバーでtest実行できない時は、lintだけでもかけておく

というかlintは設定するコスト低いので全てのプロジェクトでかけるようにはしている。

testできないものの例としては、node-ble-firmataはあらかじめ特別なファームウェアを書き込んだBLE付きArduinoを用意する必要があるので、これはどうやってもTravis CIでテスト実行できない。
しょうがないので、testは手元でやるとして、CIではcoffee-lintだけかけておく。coffeeはわりと文法間違える人いるのでlintだけでもあるとなんか安心感が違う。

普通にnpm installするとbluetooth関係のnpmをインストールしようとしてCライブラリが無くてTravis CIではビルド失敗するので、devDependenciesだけワンライナーでインストールするようにした。

language: node_js

node_js:

  - '0.10'

install: node -e 'console.log(Object.keys(require("./package.json").devDependencies).join(" "))' | xargs npm install

script: npm run lint

これでnpm run lintだけが実行される。

ちなみにnpm install –devしたらdevDependenciesだけインストールできそうだったんだけど、依存解決が無限ループして20分ぐらいインストールし続けて終了するのでやめた。

複数の言語でテストする

socket.io-client-simple gemなんかがそうで、nodeで立てたsocket.ioサーバーにrubyで接続して通信できるかテストをしている。

.travis.ymlでメイン言語をrubyにして、それとは別にnodeのバージョン指定をするとrubyもnodeもインストールされる。npm installはbefore_scriptのタイミングでやると、gemのインストール→npmのインストール→rake test実行 という順番になる。

language: ruby

node_js:

  - '0.10'

rvm:

  - '2.1.2'

before_script:

  - npm install

slackに通知する

Travis CI: Configuring Build Notificationsに書いてあるが、slackでtravis integrationを追加してtokenを取得してから、

% travis encrypt "[account]:[token]" --add notifications.slack

で.travis.ymlに通知設定が保存される。CI終わったらslackに通知が来る。

その他

あとは、READMEにサンプルコードの実行方法を書いておいたり、基本的な機能がすぐ試せる実行コマンドを付けておくとissueとかのトラブルシュートに役立つ。なんかきかれたら「〜〜を実行できる？」とか質問しやすい。

coffee-lintで1行の文字数が最大80文字という設定がデフォルトになってるけど、80文字というのは昔のパンチカードの文字数が80文字だったからMacとかのターミナルの横幅もデフォルト80文字になって未だに引きずっている意味のない数値らしいので、80文字にこだわる必要はない。
むしろ長いURL文字列を作る時とかに書きにくくなる。coffee-lintでは0を指定すると制限解除できる。

    coffeelint:

      options:

        max_line_length:

          value: 0

1ヶ月ぐらい前だけどhubotからgithubにissueを建てるのを作った。

チャットからissueのリストを見たり作ったりできるので手軽。なんか雑用を思いついたらToDoというリポジトリにissue立てるみたいな運用されてる。

githubot

hubotからgithub apiを使う場合、githubotというnpmが便利だった。
githubotはbranchのリストを取る便利メソッドとかはあるけど、基本的にGitHubのAPIをgithubot.get(url,data,callback)とgithubot.post(url,data,callback)で直接扱う。

以下はgithubot 1.0.0-beta2を使っている。

セットアップ

HUBOT_GITHUB_TOKENという環境変数を使うので、

curl -i https://api.github.com/authorizations -d '{"scopes":["repo"]}' -u "自分のユーザー名"

を実行してAPI tokenをもらって、herokuに環境変数セットする。

heroku config:set HUBOT_GITHUB_TOKEN=a1b2cdef3456

なおissueはtokenを作ったユーザー名で建てられるようになる。

実装

Issues | GitHub APIをgithubotのpostに渡すだけでissueが作れた。

githubのAPIが綺麗に規則的にできているので、githubotもよくあるかっちりしたAPIラッパーである必要がなく、tokenとかパラメータの渡し方の部分だけよしなにやってくれる薄いライブラリになっている。
なんか下手にAPIリクエスト先のpathを規則的にメソッド名に変換しているとか、そういうのじゃなくてURLをそのまま書く方がわかりやすい感じがする。APIとライブラリ両方のドキュメントを突き合わせて読まずに済むのはよい。

https://github.com/masuilab/slack-hubot/blob/master/scripts/github_issue.coffee

debug = require('debug')('hubot-github-issue')

repo  = process.env.HUBOT_GITHUB_ISSUE_REPO or "masuilab/todo"



module.exports = (robot) ->

  github = require('githubot')(robot)



  ## list issue

  robot.respond /issue$/i, (msg) ->

    debug "get issues list (#{repo})"

    github.get "https://api.github.com/repos/#{repo}/issues", {}, (issues) ->

      issues = issues.sort (a,b) -> a.number > b.number

      texts = ["https://github.com/#{repo}/issues"]

      for i in issues

        texts.push "[#{i.number}] #{i.title}"

      debug texts

      msg.send texts.join '\n'



  ## create issue

  robot.respond /issue (.+)$/mi, (msg) ->

    who = msg.message.user.name

    body = msg.match[1]

    debug "create issue #{body} (#{repo})"

    query_param =

      title: body

      body: "#{body}\n\ncreated by #{who} & hubot"

      labels: ["fromHubot"]

    github.post "https://api.github.com/repos/#{repo}/issues", query_param, (issue) ->

      text = "issue created\n#{issue.html_url}" or "issue create error"

      debug text

      msg.send text

こういうdiffとか見れるやつ

ブランチ間とか
https://github.com/shokai/irkit-device/compare/master…tempe_sensor

release tagとか
https://github.com/irkit/device/compare/v1.3.5…v2.0.1

とても便利だけどプルリク画面からしか見れない、表から辿りつけない画面な気がする。

よくURL忘れてたどり着けなくなるので、どこクリックしたらいいとか知ってる人は教えてほしい

動作を説明するのが楽。
githubはmarkdown内で普通にimgタグ使えるのでgif貼っていくといいと思います。



なおgyazoの画像をそのままblogなどに貼ると、アクセスが集中した場合に画像が埋め込めなくされ
る事があった時期もあったけど（今はないらしい）、
githubは自動的にimgタグをCDNにコピーして配信してくれるので安心です。

（見る人が少ない社内gitlabとかも問題ないと思う）

README.mdとかにgif貼るのもわかりやすくていいですね。

以上、Gyazo GIFステマでした

連続してgithub上で活動しているとstreakが累計される。
別にお金がもらえるとかではなく、ただこれだけ活動していますよという指標なだけ。

40日ぐらいを超えたあたりから、なんだか途切れさせたくなくなる。
日々ちまちまとしたメンテをしていると途切れにくい。
1から新しい物を作り始めると、まだ動いていない物をgit commitする習慣が無いので途切れてしまう。


ちなみに日本では16時を境に次の日になる。