fuelPHPとmongodbを使ってみた
このブログでcodeIgniterを紹介したのはもう何年前だろうか。
(ノ・・)ン。。。。。。(((●コロコロッ
軽量最速のPHPフレームワークとして掲載したが、
掲載後一年ぐらい経ったときに日本で広まっていた気がする。
そのcodeIgniterのメンバーが新たにフレームワークを作っていた。
それが
一番大きな違いはライセンス。
codeIgniterはEllisLab Incの独自で、
気軽に使うにはちょっと微妙な状態になっている。
その点fuelPHPは安心のMITライセンスだ。
機能も非常に充実していてcodeIgniterの欠点も補っている。
もう一つはジェネレータ。
codeIgniterにはジェネレータが存在せず、
Controller, model, viewを手動で作成する必要があったが、
fuelPHPはジェネレータを使ってController, mode, migrationを生成できる。
Scaffoldingにも対応。
前回の記事で掲載したmongodbも標準で対応している。
なので併せて使ってみようと思う。
mongodbのインストール自体は終わっているものとしている。
詳しくは前回の記事を読んで欲しい。
mongodbをyumでCentOSにインストール(UTF8対応版)
mongodbをyumでCentOSにインストール(UTF8対応版)
UTF8対応でつまづいた。
(ノ・・)ン。。。。。。(((●コロコロッ
---
RDBばかり長いことやってきたので、
それ以外のデータベースを扱うのは概念自体を勉強しなおさなければならなくて、
全然理解が追いついていない状況。
以下の記事は内容が間違っていることだらけだと思うが。
ご了承いただきたい。
---
fuelPHPを触っていたときにmongodbに対応していることに気がついた。
ということでちょっと触ってみることに。
NoSQLという概念があることは知ってはいたものの深く関わることはないだろうと思っていたのだが、
さわりもせずに物事を判断するのは一番やってはいけないことだと思い、
丁度良いタイミングで触れそうな機会があったのでやってみることにした。
ただ、アプリケーションサーバををJavaScript(Node.js)にするのはちょっと厳しそうなので、
そこはPHPのままでやることに。
普通にyumでインストールするだけだと以下のようなエラーが出る。
以下の手順ではUTF8の対策も施している。
(ノ・・)ン。。。。。。(((●コロコロッ
---
RDBばかり長いことやってきたので、
それ以外のデータベースを扱うのは概念自体を勉強しなおさなければならなくて、
全然理解が追いついていない状況。
以下の記事は内容が間違っていることだらけだと思うが。
ご了承いただきたい。
---
fuelPHPを触っていたときにmongodbに対応していることに気がついた。
ということでちょっと触ってみることに。
NoSQLという概念があることは知ってはいたものの深く関わることはないだろうと思っていたのだが、
さわりもせずに物事を判断するのは一番やってはいけないことだと思い、
丁度良いタイミングで触れそうな機会があったのでやってみることにした。
ただ、アプリケーションサーバををJavaScript(Node.js)にするのはちょっと厳しそうなので、
そこはPHPのままでやることに。
- yumでmongodb, mongodb-devel, mongodb-serverをインストール
- jsをソースからビルドしてインストール
- libjs.so.1を置き換え
- /var/lib/mongdbディレクトリ作成
普通にyumでインストールするだけだと以下のようなエラーが出る。
MongoDB shell version: 1.6.4
Tue Dec 6 11:06:30 *** warning: spider monkey build without utf8 support. consider rebuilding with utf8 support
connecting to: test
以下の手順ではUTF8の対策も施している。
homebrewでOSXにwgetをインストール
ソースコンパイルしか無い・・・のか!?
(ノ・・)ン。。。。。。(((●コロコロッ
ターミナルを使ってて何かをダウンロードしようとするとき、
手が勝手にwgetと打ち込んでしまう。
今のところcurlで代用しているがやっぱりwgetのほうが便利だな。
インストール方法を探してみると意外に見つからない。
ソース入れれば良いんだろうけどパッケージ管理したい。
MacのLinuxでパッケージ管理ツールはなかなか全然見つからなかったが一応あった。
(ノ・・)ン。。。。。。(((●コロコロッ
ターミナルを使ってて何かをダウンロードしようとするとき、
手が勝手にwgetと打ち込んでしまう。
今のところcurlで代用しているがやっぱりwgetのほうが便利だな。
インストール方法を探してみると意外に見つからない。
ソース入れれば良いんだろうけどパッケージ管理したい。
MacのLinuxでパッケージ管理ツールはなかなか全然見つからなかったが一応あった。
git svnでSubversionリポジトリをgitでコントロール
Subversionはオワコン
(ノ・・)ン。。。。。。(((●コロコロッ
実開発ですでにgitを導入しているが、
会社ではSubversionがメインストリームになっている。
gitは後発のバージョンコントロールシステムで、
ソースコードの分散管理が可能となっている。
なのでリポジトリサーバが飛んでソースコードが消えるといった自体にならない。
(もちろん運用次第だが)
アンチSubversionで構成されている。
作者は使用に悩んだときはSubversionを参照しSubversionのとった行動とは真逆のほうを選んだとか。
ソースコード管理をgitにさくっと切り替えたくてもなかなか出来ないものなので、
現状のSubversionシステムを維持しつつ、
Gitで管理していく方法がある。
それが
(ノ・・)ン。。。。。。(((●コロコロッ
実開発ですでにgitを導入しているが、
会社ではSubversionがメインストリームになっている。
gitは後発のバージョンコントロールシステムで、
ソースコードの分散管理が可能となっている。
なのでリポジトリサーバが飛んでソースコードが消えるといった自体にならない。
(もちろん運用次第だが)
アンチSubversionで構成されている。
作者は使用に悩んだときはSubversionを参照しSubversionのとった行動とは真逆のほうを選んだとか。
ソースコード管理をgitにさくっと切り替えたくてもなかなか出来ないものなので、
現状のSubversionシステムを維持しつつ、
Gitで管理していく方法がある。
それが
git-svn
STAR Auto Testing Frameworkでドキュメント駆動開発
以前の記事でSTAR Auto Testing Frameworkを紹介した。
（作者本人も驚いていたようだ。）
今回は実践してみたのでその辺りを書いてみようと思う。
テスト駆動開発を実践する上で、
私はテストケースをというコードを書くことに異議を唱えた。
（もちろん理解者はゼロ）
理由は以前も書いたが、
テスト仕様書とテストケースという内容が全く同じで言語が違うだけもの２回も用意する意味がないからだ。
仕様書を書けばテストケースが出来上がるのが理想の形だろう。
そうすれば仕様書とテスト内容が異なるようなことも起きない。
似たような例にデータベースがある。
MySQLにはMySQL Workbenchというデータベース設計ツールがある。
（旧DB Designer4と言えばわかるだろうか。）
これでDB設計し、ER図を書くと、SQL分が発行されデータベースが出来上がる。
こうすることで設計書と実際の齟齬を無くしている。
逆にドキュメントを書かないとテストも出来ないし、
ＥＲ図を描かないとＤＢができないので、
ドキュメント作成の意識も高まるといえる。
STAR Auto Testing Frameworkは単体テストとＳＴに対応している。
前者はPHPUnit, JUnitを使用、後者はSeleniumを使うことを前提としている。
これら一つ一つだけでも一冊の本があるぐらいなのでここでは詳細な説明は省く。
そして私はJavaに明るくは無いのでJUnitのことは今回は取り上げないが内容に差はないと思う。
あと文章が長くなったので今回は単体テストだけ行う。
PHPUnitはSimpleTestと並んで割と一般的に使われているテストフレームワーク。
テストケースを作成しphpunitとコマンドを打てばがんがんテストをしてくれる。
Seleniumはブラウザを使って自動テストをしてくれるテストフレームワーク。
いくつか種類があるがSTAR Auto Testing FrameworkではFirefoxプラグインのSeleniumIDEを使うことを想定しているようだ。
では実際どのような流れになるのか。
全体的なフローは以下の通り。
重要なのは最初のテストを全部エラーになるようにし、
実装後すべてのエラーが出なくなることを確認すること。
こうすることで一つのメソッドに対する入出力を保障することが出来る。
テストのパターンは自身が想定しうる問題すべてを網羅しておくこと。
（作者本人も驚いていたようだ。）
今回は実践してみたのでその辺りを書いてみようと思う。
テスト駆動開発を実践する上で、
私はテストケースをというコードを書くことに異議を唱えた。
（もちろん理解者はゼロ）
理由は以前も書いたが、
テスト仕様書とテストケースという内容が全く同じで言語が違うだけもの２回も用意する意味がないからだ。
仕様書を書けばテストケースが出来上がるのが理想の形だろう。
そうすれば仕様書とテスト内容が異なるようなことも起きない。
似たような例にデータベースがある。
MySQLにはMySQL Workbenchというデータベース設計ツールがある。
（旧DB Designer4と言えばわかるだろうか。）
これでDB設計し、ER図を書くと、SQL分が発行されデータベースが出来上がる。
こうすることで設計書と実際の齟齬を無くしている。
逆にドキュメントを書かないとテストも出来ないし、
ＥＲ図を描かないとＤＢができないので、
ドキュメント作成の意識も高まるといえる。
STAR Auto Testing Frameworkは単体テストとＳＴに対応している。
前者はPHPUnit, JUnitを使用、後者はSeleniumを使うことを前提としている。
これら一つ一つだけでも一冊の本があるぐらいなのでここでは詳細な説明は省く。
そして私はJavaに明るくは無いのでJUnitのことは今回は取り上げないが内容に差はないと思う。
あと文章が長くなったので今回は単体テストだけ行う。
PHPUnitはSimpleTestと並んで割と一般的に使われているテストフレームワーク。
テストケースを作成しphpunitとコマンドを打てばがんがんテストをしてくれる。
Seleniumはブラウザを使って自動テストをしてくれるテストフレームワーク。
いくつか種類があるがSTAR Auto Testing FrameworkではFirefoxプラグインのSeleniumIDEを使うことを想定しているようだ。
では実際どのような流れになるのか。
全体的なフローは以下の通り。
- 仕様書を作成する
- 空のプログラムを作成
- 全部エラーになるようにテスト仕様書の作成
- テストケースの生成
- テスト実行しエラーになるのを確認
- 実装作業
- テスト実行しエラーがなくなるのを確認
重要なのは最初のテストを全部エラーになるようにし、
実装後すべてのエラーが出なくなることを確認すること。
こうすることで一つのメソッドに対する入出力を保障することが出来る。
テストのパターンは自身が想定しうる問題すべてを網羅しておくこと。
PHPUnitでprivate,protectedのメソッドをテストする方法
PHPUnitなどでテストを実行するとき、
どうしても発生する問題がある。
それは
privateメソッドをテストできない
クラスを定義するときに、
privateやprotectedのプロパティ、メソッドを定義することは珍しくも無い。
特に複数人でシステムを組んでいるときはアクセス制限は非常に重要になってくる。
ただ、問題としてテストを行う際、
外部のプログラムであるPHPUnit側からアクセスが出来なくなりテストが出来ない。
そのためにpublicメソッドにするのは本末転倒といえる。
クラスを拡張してparent::親クラスメソッドとして動かす方法もあるが、
べた書きコードならともかくフレームワークに組み込まれているものだととり回しがしずらい。
(ﾟωﾟ)? じゃあどうするの?
どうしても発生する問題がある。
それは
privateメソッドをテストできない
クラスを定義するときに、
privateやprotectedのプロパティ、メソッドを定義することは珍しくも無い。
特に複数人でシステムを組んでいるときはアクセス制限は非常に重要になってくる。
ただ、問題としてテストを行う際、
外部のプログラムであるPHPUnit側からアクセスが出来なくなりテストが出来ない。
そのためにpublicメソッドにするのは本末転倒といえる。
クラスを拡張してparent::親クラスメソッドとして動かす方法もあるが、
べた書きコードならともかくフレームワークに組み込まれているものだととり回しがしずらい。
(ﾟωﾟ)? じゃあどうするの?
そこで使うのがReflectionMethod
:: Next Page >>
powered by 
)
