2011-10-02 23:05:36
大まかな手順
- Gist にコードを貼付ける
- UserScript を使って好きな色に変える
- PowerPoint なり Keynote なりにコピペする
この方法で作られたのが, ひとつ前の記事のスライドです.
以下, もう少し詳しく説明します.
Gist にコードを貼付ける
これは特に説明いらないと思いますが, GitHub の Gist に, スライドに掲載したいコードをコピペします.
Gist ではアカウントが無くても匿名でコードを貼付けることができます.
UserScript を使って好きな色に変える
ここが一連の流れの中のキモです.
UserScript とは, Firefox であれば Greasemonkey というアドオンを使って, ページのレンダリング後にフックさせるスクリプトのことです.
要は, 特定のページの表示するときに好きな JavaScript を実行させるものです.
UserScript の設定についてはこの記事では説明しません.
なお, Google Chrome であれば UserScript は標準でサポートされています.
以下の UserScript は, PHP のコードのシンタックスハイライトを, ボク自身の好みに合わせて変えるためのものです.
Gist ではシンタックスハイライトが span タグの class で指定されています.
この UserScript では, それぞれのクラスに対して自分の好きなスタイルを追加で適用しています.
これを使うと, Gist におけるシンタックスハイライトは以下のようになります.
[caption id="attachment_1429" align="aligncenter" width="413" caption="シンタックスハイライトを変更した Gist"]
[/caption]
言語によって, 指定された class は結構異なるようで, 上記の UserScript ではカバーされていない class もあります.
上記はそのまま使うのではなく, それぞれの好みや言語によって作り替えるのがいいでしょう.
PowerPoint なり Keynote なりにコピペする
PowerPoint や Keynote は, ブラウザから文字列をコピペする際, 色や大きさといった文字の属性ごとコピーしてくれます.
それ以外でも, そういった機能を持つプレゼンテーションソフトウェアであればこの方法は使えますし, そうでないものであれば使えません.
Gist からコードを貼付けると以下のようになります.
[caption id="attachment_1434" align="aligncenter" width="402" caption="コードを Keynote にコピペ"]
[/caption]
このままだと小さすぎるので, 文字サイズは適宜調節します.
UserScript で予め文字を大きくしておくこともできますが, 文字の大きさはそれぞれで微調整するので, 貼付けたあとで変更するようにしました.
問題点
コピペ作業が多いので, コードが増えてくると結局煩雑になります.
プレゼンテーションソフトウェアの中には, プレーンテキストからスライドを生成するものがあり, それらは主にエンジニア向けにデザインされているので, コードのシンタックスハイライトに対応しているものが多いです.
そういう場合はそういった選択肢を考えてみるのもいいかもしれません.
2011-10-02 20:36:30
最近 HTML5 化した Slideshare ですが, エラーで表示できないスライドが多すぎてまともに閲覧できないようです.
この記事に掲載している Flash 版は今まで通りの問題なく表示できるのですが...
スライドが完成したのが勉強会への出発 15 分前で, 通しで練習することすらできず, 発表はかなりひどいものとなっていまいました.
最低限, スライドの流れぐらいは頭の中に入れて発表すべきですね…
スライドだけ見てわかるような作りにはなっていないので, 以下で補足したいと思います.
ただし, 序盤は省略し, 本論となる書法編とパターン編についてのみとなります.
それぞれ該当するスライド番号も付記してありますので, よければご活用ください.
書法編 1: ヘルパーメソッドを使う (25 ~ 30)
テスト対象のオブジェクト, それを生成するのに必要な依存オブジェクトの生成には, ヘルパーメソッドの使用を検討しましょう.
new するだけで済むものであればそれでもいいのですが, 生成に複雑なステップを踏む必要がある場合に威力を発揮します.
これは一般的なプログラミングにおけるサブルーチンみたいなものだと思って問題無いと思います.
ただし, 可読性を問題にするのであれば, 多少長くても説明的でわかりやすいメソッドの命名を心がける必要があります.
テスト対象の生成が複雑だと, 複数のテストの比較が大変になります.
ヘルパーメソッドを使うことで, テスト A とテスト B はどこに有意な違いが有り, 結果に違いが生まれるのか, ということがわかりやすくなります.
書籍 では, Fixture Setup Patterns において Creation Method という名前で紹介されています.
また, これの応用として, 引数付きの Parameterized Creation Method というものも紹介されています.
書法編 2: テストメソッドを分割する (31 ~ 36)
ひとつのテストメソッド内で, いろんなことをテストしようとすると, 何をテストしようとしているのかがわかりにくくなります.
例え同じメソッドを対象にしたテストであっても, 前提条件等が違うのであれば, 分割するべきです.
分割することで, それぞれのテストメソッドには, より具体的な名前をつけることができます.
これもまた可読性に寄与すると言えるでしょう.
これは癖のレベルの話なので, 普段からテストを書いている人であれば無意識にそうなると思います.
まずは 1 つのテストメソッドにおいてアサーションは 1 つまで, というルールを課すことで自然とそういう書き方に近づくと思います.
パターン編 1: 依存性は外から差し込む (39 ~ 49)
スライドでは, フレームワークによくある Request クラスを例に, $_SERVER といったスーパーグローバル変数を使ったときに起こる問題について説明しました.
$_SERVER を使った実装でもちゃんと動作するので, 問題と見なさないこともできます.
しかし, 問題はテストを書こうとしたときに顕在化します.
スーパーグローバル変数に限らず, グローバル変数を利用した実装だと, 複数のテストが影響し合う可能性が生まれます.
スライドではコードで例示しているので, 具体的にはスライドの該当箇所を参照してください.
スライドのように unset($_SERVER['HTTPS']) とすることで回避できますが, コードベースが巨大化すると, 暗黙的なコンテキストが肥大化し, テストを書くのがだんだんと困難になります.
その代わりにどうするのかというと, スーパーグローバル変数 $_SERVER を直接参照するのではなく, コンストラクタやセッターメソッド等で, 引数として差し込む, という方法を採ります.
Dependency Injection (DI, 依存性の注入) というパターンです.
DI を採用することで, 再利用性が高くなるので, テストを書くことで設計が向上する例としては比較的よく挙げられます.
パターン編 2: 外部への依存を避ける (50 ~ 62)
ひとつ前の話を逆に言っているだけですが, 別の側面から解説しています.
外部への依存としては, 例えば以下のようなものが挙げられます.
- グローバル変数/スーパーグローバル変数
- ファイルシステム
- Web API やデータベース等のネットワーク
しかし, もちろんこれらを完全に避けてのアプリケーション開発は考えられません.
それではどうするのか, ということで, スライドでは Active Record の問題点と, それを解決したパターンとしての Data Mapper を例に説明しています.
ここでいう Active Record というのはパターンとしての Active Record で, 書籍 で紹介されています.
Ruby on Rails の ORM としての ActiveRecord は, それを実装したものです.
Active Record においては, 1 つのレコードが 1 つのオブジェクトにマッピングされ, それぞれのレコードはデータベースを知っています.
なので, $record->save() といった操作が可能になります.
Data Mapper でも 1 つのレコードが 1 つのオブジェクトに, という部分は変わりませんが, それぞれのレコードはデータベースのことを知りません.
例えば users というテーブルであれば, User クラスがその 1 レコードを表し, UserMapper はテーブルを表します.
(実際にはテーブルをラップしたクラスとして実装されることが多いと思いますが, ここでは単純化しています)
レコードはデータベースのことを知らないので, レコードを保存する際は $mapper->save($record) といったようにする必要があります.
それでは Active Record の何が問題なのか.
Active Record ではレコードがドメインロジック (ビジネスロジック) を持ったドメインオブジェクトとしての側面と, データアクセスを行うオブジェクトとしての側面を持つことになります.
それぞれは全く違った関心事なので, 関心事の分離 (SoC) や単一責任原則 (SRP) といったソフトウェア開発の原則に違反することになります.
テストに関していうと, データベースへのアクセス無しにドメインロジックをテストできない, といったことが起こりやすくなります.
(もちろん, 実装によりますが)
逆に Data Mapper ではドメインロジック (上の例でいうと User クラス) をデータベース無しでテストできます.
データベースに対してテストを書きたいときもありますし, そのためのテクニックもいろいろとありますが, まずはそれらを無視してテストできるようなクラス分割を行うことで, 低コストで確実にテストを書くことができます.
パターン編 3: Singleton を避ける (63 ~ 71)
Singleton は GoF のデザインパターンの中では最も理解しやいもののひとつで, よく使われるパターンのひとつです.
しかし, 同時に批判的意見の多いパターンでもあります.
Singleton ではクラスの static プロパティとしてオブジェクトとその状態がグローバル空間に残ってしまいます.
これはつまり, グローバル変数と同様の性質を持っている, ということができます.
また, グローバル変数と違って, 容易に上書くこともできないので, テストをする上ではさらに厄介な存在といえます.
対策としては以下が考えられます.
- 状態を初期化するためのメソッドを用意する
- アプリケーション本体では getInstance() といった, 常に同一のインスタンスを取得するメソッドの使用を規約化し, テストでは new でそれぞれ独立したオブジェクトを生成し, テストする
また, PHPUnit にはこれらを回避するための --process-isolation オプションであったり, @runTestsInSeparateProcesses アノテーションといった機能もあるのですが, それらについては説明しませんでした.
Singleton を使わなければ, これらの機能について理解する必要もなくなりますし, これらは Slow Test (テストの実行が遅くなる) 問題を引き起こします.
Singleton で実装したくなったとき, 本当に Singleton である必要があるのかについては, 一度考えてみる必要があるでしょう.
参考文献
スライド中に挙げたものです.
書籍へのリンクにはアフィリエイトタグをつけています.
xUnit とというのは SUnit (Smalltalk), JUnit (Java) といったナントカ Unit 系テスティングフレームの総称です.
例として示されるコードは Java のものが多めですが, PHPUnit も書き方を含めて xUnit と呼べるものなので, この書籍で挙げられている考え方やテクニックは, ほぼそのまま適用できます.
鈍器として人を殺せる程の分量がありますが, 気になるトピックをつまみ食いすることもできます.
PHPUnit の作者 Sebastian Bergmann を初めとする豪華な著者陣による, PHP アプリケーションの品質, テスト, 設計についての書籍.
Symfony の作者 Fabien Potencier による章もあります.
ソフトウェアの品質についての解説などは他の PHP 本にはまず無いものですし, 非常に刺激的な 1 册です.
アプリケーションのアーキテクチャパターンについての書籍.
全体的な分量からするとほとんど読めていないのですが, スライド中の Active Record や Data Mapper について参考にしました.
GoF によるデザインパターンを PHP に翻訳して紹介している書籍.
新卒の頃に読んで衝撃を受けました.
残念ながら絶版なので買うことはできませんが, 原稿が公開されているので, 読むことはできます.
是非電子書籍化して欲しい 1 冊です.
こちらはスライドです.
2011-09-17 17:26:20
php-build とは
コマンドライン一発でソースコードのダウンロード, 展開, ビルドまで自動でやってくれるツールです.
ところで Ruby にも ruby-build というツールがありますね.
環境について
最悪壊れても困らない環境で試すことをオススメします.
今回は開発用 VM 上の Ubuntu 10.10 で作業を行いました.
php-build のインストール
GitHub の php-build プロジェクト上で特にインストール方法について説明されていません.
ここではホームディレクトリ上の .php-build というディレクトリにインストールし, そこにパスを通す, という方法を採ります.
.zshrc の部分については, Bash を使っている場合は .bashrc に置き換えてください.
以下のようにコマンドを実行して, 同様の結果が得られれば php-build のインストールは完了です.
php-build では各バージョンの定義ファイルを元にビルドを行うのですが, これは定義ファイルの一覧です.
ここに列挙されているバージョンであれば php-build でインストール可能です.
5.4.0 beta1 用の定義ファイルの追加
GitHub に置いてますので, 以下のようにして追加することが可能です.
再度 php-build --definitions を実行すると, そこに 5.4.0beta1 が追加されていることを確認できるはずです.
依存パッケージのインストール
PHP 本体をビルドする前に, 依存するパッケージをいろいろとインストールします.
比較的クリーンな状態での Ubuntu 10.10 で PHP 5.4.0 beta1 をインストールするには, トライアル & エラーを繰り返した結果, 以下のようなパッケージが必要なことがわかりました.
依存パッケージが足りずにビルドにコケるようであれば, エラーメッセージから判断して, 適宜追加する必要があります.
PHP 5.4.0 beta1 のビルド
以下のようなコマンドを実行して, あとはひたすら待ちます.
第一引数が定義ファイルの名前で, 第二引数が出力ディレクトリです.
ディレクトリの指定はフルパスで行う必要があるようなので, 注意しましょう.
いろいろ warning が出るけど, とりあえず気にしない.
実行してみる
以下のようなコマンドを実行し, 同様の結果が得られればとりあえず成功です.
Short Array Syntax が取り入れられていることがわかりますね.
次回は phpenv と連携させて, もう少し幸福追求してみようと思います.
あと, make test とかする方法があると嬉しいですね...