トップ 最新 追記

2012-04-02 [長年日記]

_ kanazawa.js v1.7に行ってきた

[2012-04-09 追記]


いつも思うが kanazawa.js はサポートスタッフがすげぇ。

2ヶ月。これで頭がいっぱいでした。ぶっちゃけ。

スライドのレビューを受けてくれた皆さん、ありがとうございました。最後は頭領に一刀両断にされてしまいました(笑うとこね)が、その甲斐もあってなんとか時間内に必要なことは喋り終わり、質疑にも応じることができました。

事後報告でスライドの引用を了承していただいた和田さんには、実は資料からは削除したスライド中で登壇してもらったりしています。重ね重ねありがとうございます。(引用元明示してないんだけど…)

前日までの段取りや会場の準備や受付をしていただいたスタッフの皆さんありがとうございました。

久しぶりの発表で出だしはイマイチでしたが、なんとか笑いも拾うことができ、Togetterを見る限りは何人かには興味を持ってもらえ、懇親会でも何人かから突っ込んだ質問を受けることができました。ちゃんと伝わったんだなーとホッとしています。

推敲の段階でバッサリ捨てた資料を回収してリンクだけでも張ろうかなと思ってはいるんですが、とりあえず無事終わってよかったという気持ちだけ置いておきます。

あえての電波マシマシです。初めて外部のサービスにスライド置いたわ。

あとは注釈とか言い訳など。

  • スライド中のコードがモノクロなのは showoff + pdfkit の仕様みたいです。見づらくてごめんなさい。(発表のときはハイライトされてたんですが)
  • 回転と言えば「ろくろ」、だからWeb業界はテストと相性がいいです、というネタを完全にすっ飛ばしてました。
  • 懸命に削りましたが、詰め込みすぎてごめんなさい。

関連して最近考えていたことなどは別エントリに起こそうと思います。


自分のやり方

今のところ自分は jasmine gem で HTTP サーバ起こしてブラウザで開いて、guard-livereload でブラウザに自動的にリロードさせて回すことが多いです。Rubyist なので、Ruby でまとまってると楽ですね。

今後の課題とか

現実的に Web のフロントエンドの JavaScript で TDD をやろうとするときに必要となりそうなものを挙げていくと

  1. fixture ( DOM の準備 )
  2. stub, mock ( Test Double )
  3. Ajax, Timer の double と非同期テスト
  4. テスト実行の負荷軽減 ( guard-livereload など )
  5. テスト記述の負荷軽減 ( CoffeeScript )
  6. 分散バージョン管理システム ( Git, Mercurial など )

辺りでしょうか。これらを理解、実践できるようになると強いです。

テストについての知識
  • fixture ( DOM の準備 )
  • stub, mock ( Test Double )
  • Ajax, Timer の double と非同期テスト

辺りの話は、特に fixture は押さえてないと厳しいかなと思います。目視の負担や不確実性を少しでも排除したいなら必須と考えていいんじゃないでしょうか。

Ajax は恐らく今の Web では避けて通るのは難しく、そのために非同期のテストやリクエストのすげ替えができるとよいです。と言っても非同期で処理しなければテストできない部分は多くないので、ギリギリまで避けて通ることもできますけど。(ただ、往々にしてこのギリギリで避けた部分にミスが入り込むんですが)

テストの記述や実行環境の知識
  • テスト実行の負荷軽減 ( guard-livereload など )
  • テスト記述の負荷軽減 ( CoffeeScript )

ここら辺ができるととても楽に TDD のサイクルを回すことができるようになりますが、いずれにせよ KUROIGAMEN を完全に排除するのは難しいかなぁという印象があります。何か一つ、Ruby でも node.js でもなんでもいいから使えるものを用意できると強いです。まぁ我慢しようと思えばできなくもないですけど。使えないと TDD できないのかと言われれば、なくてもできます。

バージョン管理

もう一つ、決定的なものは

  • 分散バージョン管理システム ( Git, Mercurial など )

を使えるとよいです。とてもよいです。

というのも、小さく進めるたびに進捗を確実に記録できるので、これがまた安心に繋がります。一応 Green のテストを維持しながらリファクタリングすることで安心を確保できるのですが、リファクタリングの際にバッサリとコードを削れる(削っても元に戻せる)という安心感も大切ですし、特に分散バージョン管理システムは

  • 小さなステップ単位で他に影響しないツリー(branchなど)を作成できる
  • できあがってしまったらあとでこの小さなステップはまとめてしまえるので、後から読む人にとっても読みやすい記録にできる

など、TDD と相性がとてもよいのです。

ただ、セミナー形式ではここまでやろうとしても眠いだけなので、ハンズオンの機会があるといいかなぁという感じですね。それが kanazawa.js になるのか kanazawa.tdd みたいな何かになるのか、何も考えてないですけど。

そう言えば自分でも CoffeeScript を使ったテストの記述はやろうやろうと思いつつまだやってないですね。考えたら jasmine + guard なんだから spec/coffeescripts とか作ってそこからどんどん変換してやるだけですね。今度やってみよう。


リンクだけ抜き出したり足したりしてみます。もし興味があったら掘ってみてください。

関連リンク

スライド関係
TDDBC関係

関連エントリ


2012-04-03 [長年日記]

_ TDDとかなんかについて最近思っていたこと

つーことで kanazawa.js v1.7 が終わりまして、ようやく JS と TDD の呪縛から解放されて楽になった wtnabe です*1。はてブの少なさにやや放心していたりしますが、まぁね、すでに TDD 分かってる人や興味があった人には新しい内容は何もないし、開発しない人は興味ないよねーと必死に自分を慰めています。

まぁそれはともかく、今回はリファクタリングしたかった話の続き。最近感じていることをつらつらと書いてみます。

TDDは目的ではない

これは PG_kura さんの考えや疑問

テスト駆動開発は戦略である - 偏見プログラマの語り!

を読んで、スピリチュアルなメッセージを届けようとしている自分がどうにか断言調で出した答えです。当たり前すぎてばかみたいですが、しょうがないです。そう思ったんだもん。

今回のトークでは、紹介して、さあやろうと言いながら、目的じゃないしこだわりすぎるな、無理するなできることからやれ、とやや矛盾したメッセージをそのままぶつけています。混乱されるかもしれないとは思ったのですが、今の自分の正直な気持ちです。これは以下のようなことを考えてのことです。

  • テストコードを書くことも書かないこともコストである*2
  • テストコードが書けないこと、書きにくいことに対してどこまで突っ張るか決めるのは自分(たち)

これはイベントでは伝えませんでしたが、最近それなりに意識していることです。というのも、自分のテスト厨度はこれまで以下のように変化しています。

  1. リファクタリングしたいしテストを自動化して楽したい
  2. 自作ライブラリでテスト書くの楽しくなる
  3. (しばらく飛んで)TDDBC に参加してますますテストでちゃんとドライブしたいと思うようになる
  4. アプリを TDD で書く難しさを感じる
    • rspec-rails でのテストのほんとのコツは実はそんなに紹介されていない
  5. やれるところからやるに決まってんだろ(開き直り)
    • View はとりあえず従来通り目視、JavaScript も本当にややこしいと感じた部分以外はテストしない。
  6. あ、もしかしてこれでいいんじゃないか
  7. (ちょっと飛んで)そうだ、目的はリファクタリングだった
  8. てゆーかそもそもの目的は TDD でもリファクタリングでもなくね ← イマココ

つまり以前ほどにはテスト書かなきゃ、うわーっていう感情はないです。しかし今でもテストの実現方法がよく分からずに悶々として想定以上に時間が掛かってしまったりすることはありますし、当初ノーテストで進めた部分にもあとでテストを足したりはしています。

一方、TDD やテスト作成についてときどき挑発的なメッセージを発するきしださんは実は3年前に「リファクタリングできることが大事で、そのためにテストが使える」「諦めも肝心」という、この間自分の使った言葉にすでに到達され、恐ろしいまでに上手にまとめられています。

なんだよここに全部書いてあんじゃん

と思ったのですが、よくよく思い出すと関連記事を自分は当時ブックマークしています。つまり、読んでも理解できなかったんですね、たぶん。

変えればいいじゃん

今はリファクタリングや変化を包容するフレームワークのおかげで「必要になったら変えればいいじゃん」と思えるようになっています。(もちろんそれが許されるものしか作っていないわけですが。)恐らくこの状態こそが自分の望んでいた心理状態なんじゃないかなと感じています。 以前は「とりあえず」「やりやすいことだけ」やってお茶を濁していました。自信がなかったからです。

ハタから見ると YAGNI ととりあえずの違い、アジャイルとバータリーの違いは分かりにくいような気がします。でも全然違います。今はこの状態を足がかりに、これまで挑戦しにくかったことやずっとやってみたかったことにチャレンジしやすくなっている気もします。

改めてTDDをどうやって始めるか

上の自分の振り返りと TDDBC の経験を踏まえると

  • ライブラリから入るやり方はテストには慣れるけど変化には慣れないかもしれない

と思います。設計をすっきり決めやすいライブラリの場合、テストの作成に慣れ、テストを網羅するにはもってこいなのですが、テストの充実が目的化しやすいかもしれないなと感じています。

そしてここが肝心なのですが、実はこの場合はテストは開発を駆動していないかもしれないなとも思います。設計がバシッと決まりすぎてしまうものは、テストの自動化には向いていてもテストコードが開発を駆動する感じに乏しいのです。TDDBC北陸でライブラリを試しに実装していたチームの感想もそうでしたし、自分自身もライブラリからユニットテストの充実に向かいましたが、少しずつ作っているかというとそうでもないんです。テストは後付けでも全然問題ない。

だから自動テストに慣れるという意味ではライブラリから入るのはオススメですが、TDD に慣れるという意味では少し違うかもしれません。

  • テスト支援の手厚いフレームワークでアプリを作る

自分に言えるのはやっぱりこれくらいしかないです。特に Web は

  • 突き詰めると文字列のやりとり
  • 突き詰めると request と response の関数

という特徴を持っており、大変 TDD 向きです。

フレームワークから作っちゃう場合はもうどうしたらいいのか分からないです。実際には PHP でオレフレームワークを作ったことはありますが、Model 以外をテストするのはとても難しいシロモノになりました。結局自分の作ったライブラリが極めて Model 向きだったからなんですね、これ。

経験した以上のものはいきなり作れません。

「崩し」を受け止め、前へ進む

最後に TDD や OOP などに対する最近の自分の感覚を並べておしまいにしたいと思います。

  • テストしやすさのために教科書的な OO を崩すことも良し
  • 目的の達成しやすさのために教科書的な TDD を崩すことも良し
  • まったく TDD でなかった頃の自分の成果を否定しない。ログからアプリの様子が分かるのだって大事なスキル。

そのうえで、ただ消耗していく方法しか知らない状態、ただ崩すしかできない状態は否定します。それは35歳定年説に通じる道だと思うからです。自分のやろうとしていたことはがむしゃらな体力勝負じゃなかったはず。まだまだパターンなども苦手ですし、これまでチャレンジしてこなかったものも作ってみたい。体力で勝負しないんなら

智慧と勇気

でしょ。

Tags: TDD

*1 本当はその間に Ruby技術者認定試験の Silver も Gold も受けてるので全然呪縛じゃないけど。

*2 書くことで一方的にコストが減るわけでも増えるわけでもない。


2012-04-09 [長年日記]

_ JSTDD Intro followup for kanazawa.js v1.7

Q.『テスト駆動JavaScript』は必読?

kanazawa.js はデザイナの参加も多いので、個人的には『テスト駆動JavaScript』はオススメしません。いい本だと思いますがガチエンジニア向きです。

  • JavaScript そのものの話が完全にガチ
  • Java アプリを KUROIGAMEN から起動できて当たり前

など、ハードルは高いと言わざるを得ません。

同時に、この本で使う jsTestDriver もオススメしません。準備もやや面倒だし、サーバとかクライアントとか意識しなくちゃいけない。

js-test-driver - Remote javascript console - Google Project Hosting

もちろん jsTestDriver 自体はよいツールです。

  • コマンドラインから自分の好きなタイミングでテストを実行可能
  • しかもキャプチャしたすべてのブラウザで同時にテスト可能
  • 複数のブラウザのテスト結果がすべて自分の手元に返ってくる

ここら辺はフロントエンドエンジニアにはとてもオススメなのですが、こういう環境に慣れていない人の JSTDD の入り口としては厳しい気がします。

あと個人的には jsTestDriver は生で使わずに npm にある jstestdriver-wrapper で使う方が楽でいいと思います。(結局 KUROIGAMEN だけど)

問題はあとから jsTestDriver の恩恵に与れるかどうかだと思うのですが、できます。jsTestDriver には各種 adapter があるので

例えばすでに QUnit や Jasmine で書いたテストがあったとしても、複数のブラウザを効率的に検証したいときだけ jsTestDriver を使う、といった活用も考えられます。

もちろん jsTestDriver に慣れたから昔のテスト書き直すわーっていうのもアリだと思います。最初の選択、導入をしっかりやるのも大事ですけど、どうせ変化するのであればさっさと始められる方が個人的にはよい気がします。少なくとも最先端を突っ走らなければ失敗の可能性は減らせます。*1

Q. 他のフレームワークは?

2011年後半辺りは

の名前をよく聞いた気がします。Vows は思いっきり node.js って書いてあるのでブラウザの話と合うのか疑問なのですが、mocha はブラウザもサポートしてますね。

あと、テスト込みのフレームワークもあるので、その場合は付属のものを使った方がよいと思います。

なんかが代表でしょうか。

これまで jQuery くらいしか使っていないのなら QUnit や軽めのものでもよいでしょうし、大きめのフレームワークを導入してより本格的なアプリを組む場合は採用するツールの作法に従うことになると思います。

すいません、超無難な感じで。

*1 jsTestDriver, QUnit, Jasmine すべて最先端ではありません。すでに実績があります。


2012-04-10 [長年日記]

_ CI始めました

Welcome to Jenkins CI! | Jenkins CI

なんとなく Java はメンドイという思い込みで避けていたんだけど、先週末にちょっと思い立って Jenkins のインストールを試してみた。Debian で試したところものすごく簡単だったので職場にも起こしてみることにした。

DebianにJenkinsをインストール

Debian 6 にJenkinsをインストール - cactusman日誌

を参考に。

まずインストールはとても簡単。各種パッケージシステム用にパッケージが用意されてるから。

自分は Debian を使ったんだけど、上のエントリと java のパッケージが違う以外は

apt-key add
apt-get update
apt-get install

でイケた。これだけで、

  • jenkins ユーザーの作成
  • daemon の起動スクリプトと必要な設定

が展開されるので、あとは

/etc/init.d/jenkins start

するだけ。ここら辺とてもよく Debianize されてる印象。

Debian + Jenkins の考え方

  • jenkins ユーザーでプロセスが動いて
  • jenkins ユーザーのホームディレクトリ以下に各種情報が集まっていく(そういう設定ファイルが自動でセットされる)

ので、この jenkins ユーザーの扱いがキモになる。

インストール後にやったこと

  • jenkins ユーザーのホームディレクトリ変更
    • デフォルトは /var/lib/jenkins 以下になるんだけど、ここはそんなに容量用意してなかったので、別ディスクに移動
    • jenkins の設定ファイルと /etc/passwd のホームディレクトリ設定の両方変えておく*1
  • rbenv 環境を用意して jenkins ユーザーは rbenv を通して ruby を起動するように .bash_profile を設定
    • 今はアプリ一つだけど将来的に増えた際にバージョンが合ってない可能性を考慮して*2

※ jenkins ユーザーでの作業は su と source で行いました。ログインできる必要ないので。

ジョブはとりあえず全部フリースタイルで

  • LLのジョブしかないのでフリースタイルで
    • rake spec を叩く sh スクリプト、自前のテストスイート実行の sh スクリプトを jenkins のジョブ設定画面から放り込んでおく。現在の jenkins 環境に特有の呼び出し方なのでこれはリポジトリには入れないでおく*3

Rails アプリのビルドは以下を参考にした。

Testing Rails apps with Jenkins - komagata

rvm の gemset は使っていないのでもっとずっとシンプル。要するに bundle install, rake db:migrate, rake spec するだけ。

ちょっとハマったこと

  • ジョブ名にスペースを入れると workspace にそのまま反映されて、sh スクリプトやら make やらパスにスペースが入っている場合を考慮していないものが軒並み失敗する
    • スクリプトをいじるのは面倒なのでジョブ名を変更して対処
  • メモリ不足でスコンスコン落ちる
    • rake spec で全部一度に処理しようとするとメモリが不足して jenkins が落ちる

なんとか節約する。

省メモリ Rails アプリ CI

  • spec:* を一つずつジョブに分割
  • 一つだけ SCM をポーリング
  • こいつをトリガにして別なジョブを次々に起こす

Jenkins 用語で言う上流、下流プロジェクトで対処する。

当然ディスクも手間も食うけど、一気に実行してメモリが足りないという状況は回避できる。CI サーバ落ちたら意味ないので苦肉の策。

PHP は Debian 6 の 5.3 のまま使う

実際は 5.1 が production のバージョンなんだけど、5.3 への移行を考えたうえでの CI の導入なので、Debian 6 の標準パッケージである PHP 5.3 をそのまま使うことにした。

本当は PHP についても phpfarm でも使って複数バージョンを動かせるようにするのも手なんだけど、面倒なのでやってない。

workspaceのディレクトリレイアウトに依存したsetup

PHP のアプリが特定のディレクトリツリーを利用しており、この準備を早く確実なものにするために setup 用のスクリプトを用意している。

ビルド用 sh スクリプトの中で $WORKSPACE という変数を使うと workspace のパスを得ることができるので、例えば他のジョブの workspace にある何かを使うといったこともできる。

テストが独立していなかった

rake spec を分割したところ動かない spec がいくつか出てきた。急ぐときは直接 bundle exec rspec spec/**/*.rb で動かしつつ、全体の rake spec は落ちないように注意しながら進めていたんだけど、spec:* 単位で分割したらあちこち落ちて、かつその修正に意外に時間を取られてしまった。

最初の頃は stub すごいと思って喜んで使って、最近は fixture, fixture replacement も適切に使った方がいいよねと考えながら spec を書いてるんだけど、fixture, fixture replacement を使ったときのテストの独立性がちゃんと確保できていなかったらしい。

まだまだ精進が必要だ。

あと期待していること

これでとりあえずの目的は達成できた。今のところ全自動でちゃんとビルドできるものは多くないのでジョブも少ない。ただ今後はもう少し活用できるんじゃないかと思っている。

外部ジョブの監視

Jenkins には XML の POST でジョブの結果を受け付ける機能がある。これは Jenkins の動いているホスト上で直接何かを実行していなくてもジョブの結果だけを扱えるということだ。

例えばあるホストの cron の記録をメールではなく XML にして Jenkins に POST すれば成功、失敗を記録でき、失敗のときだけメールを飛ばすということが可能になる。以前から cron のメールが多すぎてロクに見ないことを問題に感じていたので、これで少し扱いやすくできないかなーと目論んでいる。

p.s. ユニットテスト始めました から6年半か…。ずいぶん経ったな。

Tags: CI Test

*1 実際には一通り設定し終わってから容量の問題に気づいたのでちょっと苦労した。先にちゃんと設計しよう。

*2 やはり rbenv rehash を忘れますね…

*3 入れて呼ぶ方がビルドスクリプトもバージョン管理できるから良いと書かれてるけど


2012-04-14 [長年日記]

_ KUROIGAMEN恐怖症にrack-webconsoleはいかが

なんか debugger を調べていたら見つけたもの。

codegram/rack-webconsole @ GitHub

何をするものか

jQuery を使って rails console をブラウザ上で実行するもの

です。なかなか面白いでしょ。

使い方は簡単、jQuery をすでに使っていることが前提ですが、Gemfile に

gem 'rack-webconsole'

を追加して bundle install して、アプリケーションの設定ファイル(例えば Rails.root.join('config/environments/developmen.rb'))に

Rack::Webconsole.inject_jquery = true

と書くだけ。

適当なページを開いてキーボードの [ ` ] を押すと console が開きます。これは rails console そのものなので、

Model.find(1)

みたいな操作が普通に行えます。

誰に向いているか

terminal や screen などに慣れていないと rails console は場所をとって扱いにくいシロモノかもしれません。その点、エディタとブラウザで開発を進めるタイプの人にはこれはフィットしそうです。

ただし、IDE を使う人は IDE から console 開けそうなのであまり関係ないような気もします…。remote の console をどうしても terminal 使わずに開きたいとかいう要求があるなら分からんでもないですが。

イマイチなところ

  • 履歴は遡れるが補完はできない

そりゃ tab はとられちゃってますもんね…。

よく分からなかったところ

  • rake が使えるかのようなことが書いてあるんだけど、すでに console を開いてるので無理なのでは
  • Sinatra でも動くようだが思ったように動かせなかった

どなたか分かったら教えてください。

Tags: Rails Ruby Rack

2012-04-15 [長年日記]

_ ノーフレームワークのレガシーPHPがCIに乗るまで

ついに仕事で触っている PHP のコードがほんの一部のテストとは言え CI に乗った

正直これは感動ものだ。

今回はここに至るまでの長大な物語をダイジェストでお届けしようと思う。

有史以前

  • PHP 3 で作られた 1 URI : 1 スクリプト + 共通関数 時代
    • 当然のように PHP と HTML と SQL 混在
  • まともなテスト環境がなかったので似た環境をどうにか作る
  • パスとか絶対で埋め込みまくりなのでとりあえず共通のパス情報の変数に差し替えまくり
  • テスト環境用のコードと本番環境用のコードが違う

オール目視

つらかった。

みなさんの予想通りバージョン管理なんてものは存在しなかった。

素朴なPHPを徐々にclassに

  • class になれば phpdoc を書きやすくなる
  • いきなり実行しないようにすればテストしやすくなる
    • これは後から気づいたんだけど、結局フロントはロクに自動テストできてない

一時期 phpdoc に夢中になっていた。今も大事に思ってはいるが、完全に独立したライブラリのドキュメント以外には助けられた感じはあまりしない。

とりあえずテンプレートを導入してHTMLを分離

当時はテンプレートにはロジックは入ってはならないと頑なに信じていたんだけど、おかげでテンプレートを制御するコードが妙に複雑になることに徐々に気づき、Rails の View を erb で書いて以降は

結局 PHP の <?php ?> 方式は適切なスコープの分離ができないことが問題なだけで、そんなに悪くなかったんだなぁ

と思っている。

ただ PHP の <?php ?> 方式はあまりに問答無用でかなりダメだと思うけど。

とりあえずCLIで叩き回る&目視

PHP 5 への移行時に苦し紛れで使ってた方法。今の capybara のようなツールを知らなかったのでひたすら PHP の cli バイナリで実行しまくった。

  • とりあえずすべてのフロントの PHP を find で洗い出して、cd して*1叩きまくる*2
  • これでも致命的なエラーはだいたい洗い出せるので、これを毎日 cron で回して通知させて片っ端から直した

しかしテンプレートオブジェクトが clone されたかどうかがキモになる部分がいくつもあり*3、最後は目力頼みに。

今ならなんとかこれもテストできるだろうなぁ。

本番サーバの監視ツールを自作

頑張って自動で叩いたり目視したりしてたけど、やっぱ網羅はできなくて、どうしても本番サーバで問題が発覚したりした。仕方ないのでログを監視することにした。と言ってもそんなにたいしたものではなく、Webサーバの error log を監視して PHP の E_ERROR とか E_WARNING を拾って通知するだけ。

Rswatch なんてものを書いてみました

要するに拡張性の乏しい Swatch を Ruby で再発明したということです。今ならもっと賢いツールがたくさんありそう。当時は標準のパッケージで入らないものはできるだけ避けたかったのと、環境が古いので自作した。PHP 5 への移行期に 4 でも 5 でも動くようにしながら、本番環境の 4 で問題が起きたかどうかを早く知るために書いたものであり、想定している Ruby のバージョンは 1.6.8 である。すごい。

書けるところからユニットテストを

実は少し PHPUnit でテストを書いていた時期がある。しかし PHP 5 への移行を考慮して割とすぐに SimpleTest にした。当時は PHPUnit が PHP 4 用で PHPUnit 2 が PHP 5 用と分離していたのに対して SimpleTest は両対応で、テストコードを資産として残しやすいと判断したため。

以来、結局 SimpleTest を使い続けている。

今もメンテは続いており、ややマイナーではあるもののなかなか良いツールだと思う。

現在のコードは徐々になんちゃって MVC になっており*4、少なくとも M の部分とヘルパーやユーティリティ的な部分は独立してテストできるので、だいぶマシになっている。

正直どんな機能にするかよりもどうやったらテストできるか、どうやったらオブジェクトの独立性を確保できるかをいちばん考えているかもしんない。

これは以前も書いたけど要するにリファクタリング及びコードの変更をやりやすくするため。どうせ自分は失敗するから。

TestCaseからTestSuiteへ

目の前の課題にいっぱいいっぱいだったのと、当時 SimpleTest には auto runner もなく、余計なコードはできるだけ書きたくないのですべての TestCase を手で叩く仕様にしていた。本当に余裕なかったんだなぁ。

これがのちのち効いてくる。TestSuite にしようにも require した瞬間にテストが走るのでまとめることができない。しばらくして production のコードと同じく

if ( realpath( $_SERVER['SCRIPT_FILENAME'] ) == __FILE__ ) {

}

でテストの実行を囲んで、今は TestSuite を叩くとすべてのテストが自動で走るし、個別にも実行できるようになっている。

auto runner をちゃんと使うとまた違うのかも。まだうまく試せてない。PHP のバージョンを上げることができたら A continuous test runner for CLI v3 - Stagehand_TestRunner - Piece Framework を導入して楽したい。

end-to-endテストはRubyでやろうとしている

PHP にも Behat という Cucumber inspired なツールがあるんだけど、これは PHP 5.3 以降を要求するという、なかなかにハードなシロモノである。

まぁ CI サーバを 5.3 で組んだので CI サーバ上では使えるんだけど、CI でしか動かないのは面倒だし、すでに RSpec は使えるので RSpec + capybara-mechanize でいいじゃんと思っている。

ちなみに Cucumber 系はちょっと準備が面倒なのと、いちばんの理由はシナリオファイルはどんな言語でもないのでエディタのサポートが弱いという点で導入には躊躇している。テストの書き方をミスった場合にその発見に時間が掛かりそうなので。

まだこれでイケそうという手応えをつかんでいるだけで、具体的にはそんなに作業は進んでいない。

end-to-end のテストが整備できたら、今の中身はバッサリ捨てたいなと思っている。

※ ちなみに、完全に自動化するのを諦めて実装時の反復だけとにかく速くするために Selenium は導入していた。最近はあんまり使ってないけど*5

結論

ゼロから作れるならとにかくデキのいいフレームワーク使え。

特にテスト支援は安心を、DBのmigrationは勇気を与えてくれるので重視した方がいい。

CI も最初から導入しろ。テストなしに繊細なコードを書くことに比べれば Jenkins の導入は信じられないくらい簡単だ。簡単で効果の大きいことから始めた方がいい。

自分がスーパーハッカーでもっとずっとプログラミングできる立場なら、もっとずっと早くなんとかなったんだろうなぁ。

Tags: CI PHP

*1 なぜならブラウザからアクセスしたときはスクリプトの場所が cwd になるのが PHP の仕様だから、これをアテにしまくっているのだ

*2 実際にはややこしい例外がいくつもあったので YAML で除外対象を定義できる Ruby スクリプトを用意してそれで回した。

*3 PHP は 4 から 5 になる段階で、それまで代入時にデフォルトでコピーされていたオブジェクトが clone で明示しないとコピーされないように変更された。この影響が思いのほか大きかった。しかもこの変更はオブジェクトに対してだけで、built-in の array などはそのままなのでかえって混乱のもとになっていると個人的には感じている。

*4 間にとりあえずフロントコントローラ方式のオレフレームワークを組んでみたりした。これは当時増えていたフレームワークがほぼ PHP 4.3 以降を要求するのに対し、利用していた環境が 4.2 だったから。この環境の制約とそれを乗り越えるためのオレライブラリ、オレフレームワークの実装はとても勉強になった。どれくらい理解していたかと問われると甚だあやしいが、Rails や ZendFramework を参考にしていた。

*5 不安になるのは必要な情報が正しく伝わるかどうかなのに JavaScript だけでは Model の状態が分からず、どーも内部の変更の影響を受けやすい。今の自分の力では fragile test になりやすい。わざわざ rc から PHP で〜みたいなことを考えるのも割に合わない感じなので諦めちゃってる。どうしても必要なときだけ Selenium IDE から HTML 吐き出して使い回したりする。


2012-04-17 [長年日記]

_ ノーフレームワークレガシーPHPから始めるユニットテスト

巨大なアクセスを抱える大規模サイトは経験ないので分かりません。

あと、本当にレガシーな PHP しか考えてません。とにかくイマドキのフレームワークを使ってください。こんなこと気にする必要ないんでしょ?

設定

できるだけphp.iniに依存しない
  • まず、PHP のコードで設定できるものは PHP のコードで設定した方がよい
  • そうすれば複数サイトの開発のための切り替えも比較的スムーズに行える
  • extension など php.ini にしか書けないものは php.ini に書けばよい

これを踏まえたうえで、自分の場合はプロジェクトごとに .htaccess および php.ini を同時に生成する setup 用のスクリプトを用意している。.htaccess に書く rewrite の設定などもここで展開するようにしている。で、このスクリプトをリポジトリに入れてある。

必要に応じて RewriteBase も設定できるようにしておけば、ある程度は開発環境と本番環境でパスが違うといった状態でも開発可能になる。*1

こうしてプロジェクト、環境ごとの違いを setup スクリプトに与えるパラメータだけで吸収する。これのおかげで mod_php か cli かを気にせずテストできるようにしている。

今回 Jenkins を入れる際にもこの setup スクリプトのおかげで実は設定自体はすぐに済んだ。

PHPでPHPを設定する

この話はすでに PHP の設定って PHP で書いた方がよくない? に書いてある。

PHP 5.3 からは php.ini 内で path や host でセクション指定して設定を分けることができるんだけど、システムの php.ini ってプロジェクトのリポジトリには馴染まないので、別メンテになってしまってよろしくない。

iniファイル + auto_prepend_file

プロジェクトごとの ini ファイルを用意するとテストは

php -c inifile -f testsuite.php

のように実行することができる。

この inifile の中で

include_path =
auto_prepend_file =

を指定してやれば

  • 共通のライブラリのパスを設定
  • 設定用の PHP の読み込み

を行える。

実際には自分の場合は

ROOT
  .htaccess
  _test/
    .htaccess
    php.my.ini
    testing.php
  app/
  config.php
  php.my.ini
  ...

みたいな感じになってて、testing.php から config.php を読み込むようにしている。

  • 普段のアプリの実行は config.php のみで
  • テストのときはテスト用のライブラリの読み込みとか準備を testing.php で行いつつ config.php も読み込む

という流れにしてある。

まぁ testing.php は spec_helper.rb みたいなもん(ひどい)

ユニットの切り出し方

『レガシーコード改善ガイド』読め

まぁこれだけだとなんなので実際いちばんよくやったのだけ紹介。

とりあえずclassに

もう

<?php
class Klass {
  function run() {
    最初からあったコード全部
  }
}

if ( realpath( $_SERVER['SCRIPT_FILENAME'] ) == __FILE__ ) {
  $app = new Klass();
  $app->run();
}

こんなんでもよい。

いきなり順次実行さえしなければあとで必要なときに料理できる。

まさかのグローバル変数はstaticなclassに

PHP 3 の時代は require してる他のファイルのグローバル変数を前提にしているものもままあったけど、さすがに今はない…よね?

どうしてもって場合は static な class 用意してメソッド経由でメンバ変数読み書きさせればマシかな。そうすりゃこの class にログの仕組み仕込めば追跡できるし。

確認したい部分をメソッドに

メソッドに切り出す段階でグローバル変数は global 宣言が必要になるので、ついでにメンバ変数にしちゃう。

で、切り出したメソッドはできるだけシンプルな入出力を提供する形にする。ダメならメンバ変数の状態でたぶん何かが確認できるので、それをテストする感じになると思う。

重たいコンストラクタはバラす

DI だろ DI (愛だろ、愛の感じで) とは思うけど、すぐにできない場合は

class Klass {
  function __construct() {
    ...
    $this->_init_foo( $foo );
    $this->_init_bar( $bar );
    ...
  }

  function _init_foo( $foo ) {
  }

  function _init_bar( $bar ) {
  }
}

こんなんでよい。で、テストのときは

class Klass_Test extends UnitTestCase {  // SimpleTest の場合
  function setUp() {
    $this->obj = new Klass();
    $this->obj->_init_foo( $config );
  }
}

みたいな感じでテストに都合のいい設定やオブジェクトを突っ込む。

ちなみにテスト用 class の名前を

Klass_Test

にしたのは理由があって、Klass を継承してテスト用に変更するときに

TestingKlass

という名前を使うから。これは『レガシーコード改善ガイド』の中で紹介されている命名ルールに従っている。

スプラウトクラス

レガシーコード改善ガイドに出てくるテクニックのうち、いちばん好きなもの。

でかくて複雑なメソッドを丸ごとクラスに追い出してそのクラスの中でバラしていく方法。

なんだけど、

とにかくまっさらでテストしやすいclassを作る

ためにも使える。

本買って読んで!

ライブラリにする

テストしやすさのためには要するに独立していることが大事なので、当然の流れとしてライブラリ化というのは出てくると思う。

以下脱線。

気をつけないとこのライブラリこそが癌になりかねない。このソーシャルコーディングの時代に自社で閉じたライブラリを整備することは十分な切り分けを考えた上でやらないといけないと思う。

個人的には PHP は LL の中では使いやすい大きさのちょうどよいライブラリがとても少ないと思う*2ので、勢いこうしたライブラリの整備に話は進みやすいと考えている。本当にレガシーな環境(PHP 4とか)であれば仕方ないけど、そうでないならオリジナルライブラリはできるだけ最小限に留めた方がよいと思う。

Tags: PHP Test

*1 パスに関しては本当は PHP 5.4.0 以降の built-in HTTP サーバなど、他の LL のようなサクッと起動できる開発用のサーバがあれば話は簡単なんだけど。

*2 なぜかみんなフレームワークの中に収めようとする


2012-04-20 [長年日記]

_ 最小限rspec-capybara-mechanizeの準備

※ capybara は 2.0 で request spec ではなく feature spec で動くようにするなど API 変更が入っています。下のエントリは capybara 1.x 時代のものなので、gem のバージョンも 1.x になるように制限してあります。

PHP も end-to-end は RSpec で書こうと思っているという話は先日書きましたが、以前は capybara-mechanize を単独で動かしただけで rake で回せる環境になってなかったので、それを最小限の構成で準備してみました。

minimal rspec-capybara-mechanize env ― Gist

を clone して bundle install すればだいたいすぐ使えます。中身はこんな感じ。短い。ステキ。

include Capybara

は Capybara のドキュメント見ると Capybara::DSL になってるんですけど、何も考えずに bundle install した capybara ( version 0.4.1.2 ) では Capybara::DSL なんてねーよ!と怒られてしまいました。どうなってんだ。

[追記] どうもたまたま自分の入れた環境は依存性の関係で 0.4 になってしまい、include Capybara::DSL は怒られてしまうという状況のようです。gist を update して 1.0 以上でも 0.4 でもどっちでも動くようにしておきました。

構成としては

Gemfile
Rakefile
app/
spec/requests/spec_helper.rb
spec/requests/**/*_spec.rb

みたいな感じを考えてます。これで

require File.dirname(__FILE__) + "/../spec_helper"

describe 'Index' do
  before {
    visit '/'
  }
  it {
    body.should include('Copyright')
  }
end

みたいなテストが書けます。ひゃっほう。

使い方はいつものように

bundle exec rake spec:requests

です。

気をつけなきゃいけないのは、Capybara は RackTest じゃないと response とかメタデータが取れないっぽいところ。はっきりそう書かれているのを読んだわけじゃないんですが、

Capybara の README 意訳 - おもしろWEBサービス開発日記

を読むと Selenium では session や request にアクセスできないと書かれています。Mechanize だと取得できるようです。

本日のツッコミ(全2件) [ツッコミを入れる]

_ os0x [capybaraの現行バージョンは1.1.2で、0.4.1.2は一年かそれ以上前のバージョンですね。 Capyba..]

_ wtnabe [マジすか! 何も指定しなければ最新版が入るものと思い込んでました…。とほほ。]


2012-04-22 [長年日記]

_ JasmineをCLIで走らせるならjasmine-headless-webkitが楽すぎる

先日から CI づいているので今度は JavaScript のユニットテストの分を調べました。

現在のwtnabeの普段の開発手法

  • Jasmine gem と guard-livereload を使って
  • ブラウザで自動reloadさせながら Jasmine でユニットテストを書く

ということをしています。これはやっぱりブラウザで動かせる Firebug などの開発者ツールがとても強力なので、何かあったときに探っていくのに便利であることが理由として大きいです。あとブラウザで見ることができる方がなんか安心というのもあります。

しかしこのままでは CI と相性がよくありません。だから今まで CI は無視してたのです。

rake jasmine:ciはGUIブラウザ前提

一応 Jasmine gem には

rake jasmine:ci

というタスクが定義されているのですが、これは基本的に Selenium でブラウザを起動してテストを動かして結果を受け取るというもので、

基本的には GUI のブラウザが動くことが前提

になっています。ということは CI サーバで使うには X を起こすか Xvfb とか使って Firefox などのブラウザをサーバ上で動かす必要があります。これは面倒くさいうえにとても重たい。できれば避けたいです。

PhantomJSはなんでもできるけどテスト準備が面倒

ということで headless ブラウザとして有名な PhantomJS を使うのかなぁ、なんかでも PhantomJS で CI みたいな記事はやたら面倒くさい構成っぽいよなぁと思っていたら神降臨。

Twitter / @os0x: @wtnabe jasmineをheadlessで動 ...

おぉ、そう言えば jasmine-headless-webkit はすでにチェック済みでした。

ただ正直 headless ブラウザはよく分からないんですよね。結局みんな WebKit 使ってるんでしょ? なんでいくつもあるの? という感じ。で、有名な PhantomJS にしてみようか、本家のページにも Jasmine や QUnit とか使ってテスト動かせるよって書いてあるし、と思っていたのですが、結局のところ HTML を読み込んだうえで何か操作するというのが基本なので、JavaScript の読み込みやテストの実行はこっちでお膳立てする必要があります。要するに

PhantomJSはいろいろできるけどテストの実行には特化していないので準備が面倒

なんですね。

jasmine-headless-webkitですべて解決

jasmine-headless-webkit -- The fastest way to run your Jasmine specs!

そこで jasmine-headless-webkit. 何をしてくれるかと言うと

  • Jasmine gem と同じように設定ファイルを読んでくれて
  • test runner に当たる HTML を自動的に生成してくれて
  • headless WebKit ブラウザをさっと立ち上げてテストを実行して
  • 結果を CLI にそのまま表示してくれる(reporterは選べる)

というもので、使い方は単に

$ jasmine-headless-webkit

と叩くだけ。するとカレントディレクトリから Jasmine gem 標準の

spec/javascripts/support/jasmine.yml

を探しにいって*1、これを読み込んで Jasmine gem と同じように設定を解釈して動作します(たぶん)。

つまり普段 Jasmine gem でテスト書いてる人の CI 向けのツールとしてはカンペキです。何も変える必要がなく、単に叩くコマンドが違うだけ。

しかも

CoffeeScriptからの変換も全部自動で面倒みてくれます

あなたが神か。

開発者ツールで中を覗いてみたくならなければ、

普段使いもこれでいいじゃん

て感じです。いやーいいもの教えてもらいました。周回遅れは楽でいいです。はい。

あ、ちなみにこれも Ruby で書かれているので Ruby のインストールが必要ですし、qt4 やらなんやらも必要です*2。WebKit 系のこうしたツールはソースからビルドするタイプのパッケージシステムを使っている方が楽かもしれません。

PhantomJSの今後の可能性

PhantomJS のサイトからもリンクされていますが、

GhostDriver by detro

というものがあるそうです。今のところ technical-demo と書かれていますけど、Selenium から PhantomJS が使えるようになるかもしれません。これが安定して使えるようになれば Jasmine に限らずいろいろ可能性が広がりますね。

*1 オプションで変更も可能

*2 GUIのない環境では Xvfbも必要。


2012-04-26 [長年日記]

_ PHPのサイトをcapistranoで自動deployしてみた

最近バックエンドのバックエンドの整備を進めています。今回は PHP でできたサイトを Capistrano で deploy できるようにしました。

構成

今回のサイトは Rails 風のディレクトリで言うと

...
  sub/
    app/
    public/
    setup_script*
DOC_ROOT/foo -> sub/publib
...

こんな感じになっていて、DOCUMENT_ROOT のツリーの外にある public/ への symlink を作成して、そこから app/ などのコードを読む、ちょっと変わった形の PHP 製の Web サイトです。

とても残念なことにオレフレームワークでできています。

準備

ruby と bundler gem は事前にインストールしておいてください。

上の sub/ に当たる手元のツリー上で

source :rubygems

gem 'capistrano'
  • 上の内容の Gemfile を作って
  • bundle install [--path vendor]
  • bundle exec capify
  • Capfile, config/deploy.rb の編集
  • bundle exec cap deploy:setup

releases, shared というディレクトリがない限り、ここまでは従来サイトを壊さずに、かつ何もcommitせずに行えます*1

自分の場合は Capistrano そのものは他の Web サイトへの deploy や定型タスクの管理などに使っていたのでここでそれほど苦労はありませんでした。

できれば最初は Capistrano と相性のいいフレームワーク(Railsなど)で練習しておいた方がいいと思います。

setup 用のスクリプトは実際にサーバ上に展開されたあとに実行されるので、直しては commit して deploy、をくり返すことになります。ここで commit log がとても汚くなります。うぅ…。

今回の影響

上のツリーの中の

sub/

以下に直接 upload していたものが cap deploy:setup のおかげで

sub/
  releases/
  shared/

となり、sub/releases/ 以下への deploy になります。

従来は sub/ 以下で手作業で setup 用のスクリプトを叩いていたので、スクリプト内で自身からの相対パスでいろいろな作業をしていたんだけど、Capistrano から実行するには相対パスを絶対パスに直して実行する必要があります。

あとは releases/ が挟まっている場合とそうでない場合で DOC_ROOT がこのスクリプトから見て ../../ から ../../../../ にずれてしまうので、その対応をすれば ok となります。実際には実行するスクリプトが current/ 以下にあるので current が挟まっていると絶対パスを算出したときに 2階層ずれる、というパッと見分かりにくいコードになってしまいますが。

※ 開発環境などでは releases/ が挟まっていないので場合分けして従来通り動くようにしておかないとギャッとなります。

もともと考慮していたもの

たぶんこの準備ができているといないとで大きく作業時間が変わってきます。

  1. 全部バージョン管理する
  2. できるだけ設定は php.ini から分離させているので、一つのサイトだけを独立して扱いやすくなってる
  3. .htaccess などはスクリプトから自動生成
  4. このスクリプトは自身の置き場所からもろもろのパスを自動解決

このため必要なことのほとんどは setup 用のスクリプトを絶対パスで動くようにすることでした。

1 が地味にハードル高いかもしれません。実は古いサイトは無駄にファイルが多すぎたり開発者と更新者で触るファイルが混ざっていたり、そもそもバージョン管理を作業者全員に教えるのが大変とか様々な理由でバージョン管理していない場合があります。

今回のサイトは「全部」バージョン管理されています。ただし全員が中央のリポジトリにcommitできる形ではない変則的な運用になりますが*2

バージョン管理は必須と考えた方がいいと思います。安心して使えるファイル群がどれなのかが一意に決まるし、「いつの時点」も revision や commit hash で容易に特定できるからです。もちろん組織に馴染まない可能性はありますが。

DOCUMENT_ROOTからのsymlinkで公開する方法は使える

今回のサイトの公開はもともと symlink の生成で行われるので、この link が切り替わらない限り従来の方法で deploy したサイトは壊れないということが大きな安心に繋がりました*3

実は symlink 生成での公開になったのは当時としては苦し紛れだったんですが、今回はこれがとても役に立ちました。

実はDOCUMENT_ROOT 以下に直接ファイル置かない方がいろいろ便利かもしれません。

独自セットアップスクリプトはいつ動かす

deploy:restart hook に定義しました。今回はサーバの再起動は必要ないものなので、再起動させずにセットアップ用のスクリプトを動かすだけです。

まとめ

CI のときも思ったけど、ちゃんと自動化しておいてよかった。

*1 Capfile やconfig/deploy.rb は手元のものが使われるため。

*2 このため wtnabe は普段自分用に git-svn を使いつつ「共有」用に hg も使うというアホなことをしています。

*3 このスクリプト作成時や公開当初に Capistrano の current -> releases/XXXXXX の link 方式を意識していたわけではありませんでした。


2012-04-29 [長年日記]

_ UX Kanazawa Vol.2はガチ

※ 実際には 5/12(土) に書いてます。

ガチだった。マジガチ無知。

久しぶりの開催の UX Kanazawa Vol.2. 前回は「こんな感じかなぁ?」とみんなでやってみた感じだったけど、

今回はガチ

でした。

終わってすぐ連休に入ってちょっといつもと違うモードに入ったためなかなか日記を起こせなかったことと、ポイントが多すぎて書いても結局トレースするだけ(というかそれすら難しい)になって、ちょっとこれどうなんだろうという感じになりそうで躊躇しているうちに時間が過ぎてしまった。

全体の構成

  • 講義
    • Design の歴史、Human Centered Design と UX
  • ワークショップ
    • HCD手法の中からオブザベーション(観察) -> 評価グリッド -> プレゼン

の2部構成。

オブザーバというとあぁ、と思う人がもしかしたら多いのかな。

全体の感想

時間足りなすぎ。開始を1時間早めてもまだ足りない感じだった。

そして濃密すぎ。これはね、いやすごいですよ。全力で参加しないとあっという間に置いていかれる。受け手思考だと完全に置いていかれます。UX Kanazawa ガチ。ガチ硬派。

実は個人的には認知科学の話やエスノグラフィの話は初めてじゃないのでまだ参加者の中では余裕あった方だと思うんだけど、もう10年以上前にかじった程度なので思い出す余裕もなかった。

で。

バックグラウンドや姿勢にもよるとは思うんだけど、懇親会から最後まで参加した人間として思うことは、これは

ぼくの知らない金沢が生まれるんじゃないか

という気がした。WDF や DA 方面には参加したことがないからそことの比較はできないんだけど、(前回からそうなんだけど)Web に噛んでない人もガンガンきてる。これがまず面白い。全体的には IT 関係の人が多いんだけど、懇親会で話すと全然分からない話がたくさん出てくる。

ここ 1年くらいは kanazawa.js への参加が最も多くて、エンジニア以外との接点増えたかなーなんて思ってたけど、おれの知らない世界のエンジニアまだまだいるよ! もっと出てこいよ!

反省

あくまで自分の感じた反省であって、同じグループの他の人の反省とは違うかもしれないことをまず断っておきます。

  • 観察から評価グリッドで順番に問題点、改善案のヒントに上がって行くはずなんだけど、それぞれの間にやや飛躍を感じた。

これやっぱ実に難しい。

まず問題点のもとになるものが観察の中にちゃんと入っていない感じがした。自分はオブザーバをやっていたので、つまりは観察力不足ということになるんだけど、自分の気づいていない問題点を観察対象者*1がそのまま書き出していたりして、ということはやはり本当はそのとき感じていたものを思考発話が出来ていないということだし、モデレータがそれをモデレーションできていなかったということだ。

オブザーバは手間は掛かるがまずは実直に作業すればタスクは遂行できる。しかしモデレータは違う。モデレータがオブザベーションの過程をちゃんと理解し、そのうえで観察対象者とある程度信頼関係を築いて、的確に観察対象者の行動をモデレーションしてあげる必要があるんじゃないか。

実はこれ本当に大変なのは観察対象者とモデレータだよなぁと思った。

  • ペルソナについて最初に軽くジャブがあったんだけど、観察対象者とそこから導いたはずのペルソナが本当に合っていたのかなぁ?という疑問があった
  • 最終的に考えたプロダクトの利用シーンがペルソナや観察から飛躍していた

最後はペルソナをベースに「予測」あるいは「マーケティング」の要素がたぶんに入ってしまった。つまり今回のオブザベーションワークショップでは扱っていない領域に踏み込みすぎてしまった。

やっている最中は「おぉこれは面白いぞ」と思いながら作っていたので満足していたんだけれど、改めて発表の段になった際に、観察、ペルソナ、ストーリーがどれも少しずつつ飛躍する感じになってしまった。

簡単に言うと「お題」優先で、その「お題」に対する意外で面白い「回答」を「考えて」しまっていた。これはオブザベーションワークショップの趣旨とは違うし、HCD ではないし、UX を考える根拠が不足している。

改めて今回のポイントと感想

合ってるかどうか分からないけど、今回の UX Kanazawa Vol.2 でやったことは「ユーザーからどうやってデザインを決定する根拠を集めて、何を導き出すか?」そのための流れを学んでいたはずだ。なのに、最後は根拠の足りない発表をしてしまった。

デザインの決定要素はとてもたくさんあって、現実の自分はデザイナじゃないんだけど、様々な要素によってデザインが流動してしまう現場を見ている。そこで自然と「先回り」や「バランス」を重視してしまうような思考ができてしまっているんだなぁということを感じた。

今回やったようなオブザベーションは思い入れの入るエンジニアやデザイナではなく、別な立場の人が実は得意なのかもしれない。観察は作り手も参加した方がよいが、実は作り手じゃない人が参加した方が話が脱線せずに粛々と進みそうな気がしないでもない。例えば開発に対して QA のような、そんなイメージ。もし自分の作ったものをユーザーがクソミソに言いながら使っていたら冷静な観察ができないかもしれないしね。

だから実はモノ作りに関わってはいるけど営業です、とかそういう人も入った方がいいんじゃないかな、これ。モノを生み出してユーザーに届けるのって大変だけど面白いねって、直接作り出していない人も感じられるんじゃないかなぁ。

なるほどな!

って思うもん。

もしかしたら次は読書会とかの方がいいのかね、これ。アンケートで課題図書を聞いてみたけど、超定番の本以外はやはりまだあまりこなれてきていないみたい。とは言え、あんまり適当にイメージを膨らませてもダメなのかなぁとか、ちょっと悶々としたりしながらとりあえず今日のところは飲んで寝ます。

ありがとう。またよろしく。

Tags: Design UX

*1 「ユーザー」と置き換えていいのかな