RSpec 3.5のRequest Spec使ってみた

Jun 24, 2018

おじさんのためのRSpecとRequest Specの歴史ふり返り

RSpec にはもともと Request Spec はあった
Capybara 1.x 時代は Request Spec + Capybara という組み合わせはアリだったが、Capybara 2.x 時代には Feature Spec と組み合わせてくれという話になり、そっちが流行った
Feature Spec の登場は RSpec 2.14
この頃同時に RSpec 3 へ向けて should が expect なるぞーなど RSpec に疲れた人が増える（脱線）
RSpec 3.5 で Request Spec は以前に比べて高速化したのを期に Controller Spec じゃなくて Request Spec オススメだよ宣言

使ってみた感想

いくら速くなったとは言え、Controller Spec よりは明らかに重い
ただし多少の遅さは我慢のうえで Request Spec を使うメリットはある
1. view の render が自動で走るので response body も何の前準備もなしに取得できる
2. Feature Spec ではないので Capybara の語彙に縛られずにいきなり Post できる

ごく簡単に言うとまず API を叩いて response を確認するといったことが普通にできる。地味かもしれないけどこれが助かるシーンは確かに今後増えそうだ。

~/.netrcの使えないCI上からGitHubなどのprivate repositoryをprivate package代わりに使う

Jun 24, 2017

前提

deploy 先で build プロセスを動かすことのできないプロジェクトであること
~/.netrc が無効な git クライアントが動いている

※ 今回の方法は依存パッケージを記述するファイルを強引に書き換えてしまうので、Gemfile と Gemfile.lock が揃っていないとそもそも build できない Heroku x Rails のような環境では使えないはずです。試してないけど。

方法

環境変数に token を持つ
package を install する前に依存先の URI を token 付きのものに書き換える
yarn を使っている場合は yarn install –no-lockfile オプションを使う

コード

以下のようなコードを事前準備の段階で実行すれば実現できる。

#! /bin/sh

if [ -n "$CIRCLE_SHA1" -a -n "$GITHUB_TOKEN" ]; then
    perl -i.bak -pne "s/git\\+https:\\/\\/github\\.com\\/wtnabe/git\\+https:\\/\\/${GITHUB_TOKEN}\\@github\\.com\\/wtnabe/" package.json
fi

npm install や yarn install の前段階で package.json をゴリっと書き換えてしまっている。

また、単に https://github.com から始まる URI を書き換えるようにするといろいろ誤爆しそうなので git+https を入れたり工夫してある。

課題

private repository のコードを依存 package として指定したい
通常の開発時は開発者は自分の認証情報をもとに GitHub などにアクセスしており、各自がいい具合にキャッシュとかさせているので問題ない
- CI 上ではそういうわけにはいかない。なんらかの方法で認証をパスしなければいけない

試したこと

ssh key
- 最も素直な方法だが、GitHub には同一の鍵を複数登録できないので、CI のアクセスする repository の数が増えれば増えるほど扱いが大変
- CI の機能で自動的に生成される鍵なら問題にはならないが、CircleCI では自動セットされる deploy key があるとそれを他の repository にも適用しようとするみたいでうまくいかない（そらそうか）
- GitHub machine アカウントなら一つの鍵を使いまわせるっぽいけど、まだ試せていない
~/.netrc
- 以前試した ~/.netrc を利用する技は CircleCI 上では使えないっぽかった。Heroku のように deploy 先で build プロセスを走らせることができない場合は build をすべて CI 上で動かす必要があるが、そこで使えないのなら別な方法を考えるしかない

GitHub/BitbucketからAccess Tokenを使ってdeployする - あーありがち(2017-04-17)

今さら『パターン、Wiki、XP』を読んだ

Jun 24, 2012

リンク

3年前に買ってそれっきり積んでました。ごめんなさいごめんなさいごめんなさい。読み始めたら一気に読んでしまった。

ざっくり

面白かった。最近こういう本をほとんど読んでいなかったけど、丁寧に資料を集めた丁寧な仕事だ。

これまでパターンという言葉は実はあまり好きじゃなかった。意味がよく分からなかったから。その理由が本書を読んで分かった。要するにソフトウェアの世界で「デザインパターン」というパターンの中のごく限定的なものが有名になりすぎたからだったようだ。

省略せずに「オブジェクト指向における再利用のためのデザインパターン」という言葉を使っていれば「オブジェクト指向」「再利用」「デザイン（設計）」と三つも限定条件が入っていることが分かる。例えば極端な話、再利用性のないものならパターンは無用だ。「デザインパターン覚えてないしソラで書けないし、オブジェクト指向なんか分かってないんじゃないか」とか、変に萎縮する必要もないわけだ。

ちょっと安心した。

第1部建築

以下、ざっくりと心に残った言葉。

「セミラティス構造」
- トップダウンのツリー構造で抜け落ちる様々なものへの気づき
「漸進的成長の原理」
- オレゴン大学の実験における建築プロジェクトで適用された原則の中から。
親方の仕事はあとで修正がきく
- パタン・ランゲージを引用した言葉の要約だけど、アジャイルとか言わなくても昔からモノを作る仕事のコツは変わらないんだなぁという印象。
「パターン形式」
- ノウハウなどの記述形式ってよく悩むことがあるので、フォーマットを決めるときに参考になると思った。フォーマットについては Wiki の話でもモードという言葉で出てくる。

観察からボトムアッププロセスへ繋がっていくアレグザンダーの思考を鮮やかにトレースできて、そうだよなぁと次々に納得が押し寄せてくる。

第2部ソフトウェア開発

OOPSLA が何か初めて知った。

こういう論文というかアイディアの発表というフォーマットがあり、議論し、そのくり返しによってより良いものを目指すというアプローチがなんというか、プラグマティックな学会のような感じで面白かった。日本だと何になるんだろう、学会そのものとは違うだろうし、各種カンファレンスも何か違うような…。デブサミはいろいろボーダーがないので位置づけとして近いのかもしれないけど、この本で読んだ限りでは OOPSLA みたいな動き方とは違うような気もする。

脱線した。