MacBookにpearをインストールしたメモ

php Mac

Ethnaのテストを動かそうとしてローカルの環境を整えていたら、simpletestが入っていなくて、さらにpearコマンドで入れようとしたら pearが入っていなかったので、インストールをしてみた。
ローカルの MacBookでは、phpもソースインストールではないので、元々入っているやつをそのまま使っている。
普段使っている CentOSならば、yumで、と行きたいところだが、Macなので、MacPortsかなーと思って探してみたが、それらしいのは無かった。

$ port search php
$ port search pear


そこでぐぐって出てきた、こちらのサイトを参考に入れてみた。ほぼそのままですが。
「Mac OS 10.5にpearをインストール│素晴らしき哉、人生！」

今回の環境はこちら。

$ php -v
PHP 5.2.6 (cli) (built: Jul 15 2008 23:16:51) 
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies


pear.php.netから落としてきたファイルを実行する。

$ curl http://pear.php.net/go-pear> pear.php
$ sudo php -q pear.php

2回Enterをすると以下のような質問を聞いてくる。

Below is a suggested file layout for your new PEAR installation. To
change individual locations, type the number in front of the
directory. Type 'all' to change all of them or simply press Enter to
accept these locations.

1. Installation prefix ($prefix) : /Users/XXXX
2. Temporary files directory : $prefix/temp
3. Binaries directory : $prefix/bin
4. PHP code directory ($php_dir) : $prefix/PEAR
5. Documentation base directory : $php_dir/docs
6. Data base directory : $php_dir/data
7. Tests base directory : $php_dir/tests

1-7, 'all' or Enter to continue:

1を押してインストールパスを変更する。
私は、/usr/share/pear を指定しました。


このままでは、pearコマンドにパスが通っていないので、/usr/bin/以下にシンボリックリンクを作成しておく。

$ sudo ln -fs /usr/share/pear/bin/* /usr/bin/


これで、いつもの pear コマンドが使えるようになった。

$ pear list
Installed packages, channel pear.php.net:
=========================================
Package           Version State
Archive_Tar       1.3.2   stable
Config            1.10.11 stable
Console_Getopt    1.2.3   stable
HTML_Template_IT  1.2.1   stable
MDB2              2.4.1   stable
MIME_Type         1.1.3   stable
PEAR              1.7.2   stable
PEAR_Frontend_Web 0.7.3   beta
Structures_Graph  1.0.2   stable


Ethnaで必要なファイルをインストールする。

$ sudo pear channel-discover pear.ethna.jp
$ sudo pear install ethna/smarty
$ sudo pear install ethna/simpletest


pear list コマンドに -a オプションを付けて入っているのを確認。

$ pear list -a
Installed packages, channel __uri:
==================================
(no packages installed)
Installed packages, channel pear.ethna.jp:
==========================================
Package    Version State
Smarty     2.6.21  stable
simpletest 1.0.1   stable
Installed packages, channel pear.php.net:
=========================================
Package           Version State
Archive_Tar       1.3.2   stable
Config            1.10.11 stable
Console_Getopt    1.2.3   stable
HTML_Template_IT  1.2.1   stable
MDB2              2.4.1   stable
MIME_Type         1.1.3   stable
PEAR              1.7.2   stable
PEAR_Frontend_Web 0.7.3   beta
Structures_Graph  1.0.2   stable
Installed packages, channel pecl.php.net:
=========================================
(no packages installed)


このままでは、phpにパスが通っていなかったので、php.iniに記述を追加。
追加するために、まずは php.iniのある場所を探す。

$ php -i | grep ini
Configuration File (php.ini) Path => /etc

$ sudo cp /etc/php.ini.default /etc/php.ini
$ sudo vi /etc/php.ini

差分

$ diff /etc/php.ini.default /etc/php.ini
469c469
< ;include_path = ".:/php/includes"
---
> include_path = ".:/usr/share/pear/PEAR"

読み込まれているか確認

$ php -i | grep include_path
include_path => .:/usr/share/pear/PEAR => .:/usr/share/pear/PEAR


余談
ここまでやって再度、php.iniが読み込まれているか確認したところ、

$ php -i | grep ini
Configuration File (php.ini) Path => /etc
Loaded Configuration File => /private/etc/php.ini

/private/etc ?? という感じだった。
Macの /etc はシンボリックリンクなのかぁ

$ ls -l /etc
lrwxr-xr-x@ 1 root  admin  11 10 26 11:24 /etc -> private/etc

Ethna本体のテストを実行する方法

Ethna

Ethnaの動作でちょっと気になるところがあったので、テストを書きつつパッチを書こうと思ったところ、まず、Ethna本体のテストを実行する方法がわからないことに気づいた。
trunkから落としてきたファイルには、testディレクトリも、テスト実行用らしき bin/ethna_run_test.php もあるが、普通にたたくだけでは動かなかった。


wideの%Ethnaチャンネルで、mumumuさんに聞いたところ、ソースツリーのルートが Ethna という名前になってないとダメとのことでした。


Ethna本体のテストを実行するまでのメモ。
適当なディレクトリに移動してから以下を実行。

$ svn export http://svn.sourceforge.jp/svnroot/ethna/ethna/trunk Ethna
$ php Ethna/bin/ethna_run_test.php Ethna/test/Ethna_ActionForm_Test.php 
Ethna All tests

 Ethna_ActionForm_Test
  |--- test_get - OK
  |--- test_getDef - OK
  |--- test_getName - OK
  |--- test_clearFormVars - OK
  |--- test_set - OK

All OK
Test cases run: 1/1, Passes: 13, Failures: 0, Exceptions: 0


全部実行したら、adodb が無いって怒られた。

EthnaのSmartyプラグインを独立したファイルにしてみた

Ethna

IRCのwideの%Ethnaチャンネルで話していたことがきっかけなのですが、Ethnaで組み込み用意されている Smartyプラグインがあるが、現状は Ethna_SmartyPlugin.phpというファイルにまとめて書かれている。
それを、Renderer/Ethna_Renderer_Smarty,php内の _setDefaultPlugin() で、すべての関数を setPluginしている。
これだと、使用していない関数まで追加処理が動いてしまっている。
Smartyでは、命名規則に合わせたプラグインを作成しておくと、必要になったときに読み込まれるという機能があるので、そちらを使った方がいいと前々から思っていた。


今回、IRCで話したこともあったのと、ちょうど沖縄に来るタイミングで飛行機に乗っている間に時間があったので Smartyプラグインをファイルに分割してみた。
動かしながらテストしたが、少し違和感のある動作をする部分もあったので、それを直してから本体に取り込めればと思います。


とりあえず現状。
http://maru.cc/tmp/ethna_smarty_plugin.patch
http://maru.cc/tmp/ethna_smarty_plugins.tar.gz
ごらんの通りtmp領域なので、取り込まれたら消しちゃいます。


Smartyプラグインは、class/Plugin/Smarty/ 以下に置くようにしています。


i18n系の関数の挙動を整えたり、number_formatの 0を渡したときの挙動とか変えて、テストも書かないとですね。
テストを書くのに、今までの、test/Ethna_SmartyPlugin_Test.php ではなく、ファイル単位の方がいいかと思うので、テストが下階層もみれるようにテストを修正してから、テストを書いてですね。


いろいろやりたいことがあって楽しい。

追記(2009-01-21)

遅くなりましたが、Smartyのプラグイン分割をEthnaのtrunkにコミットしました。
そろそろ公開される Ethna-2.5.0 preview3(beta) に取り込まれる予定です。

デザイナーとの協業での工夫　Smartyプリフィルタの活用法

php

いま行なっている案件で、社外のデザイナーさんが作ったデザインをシステムに取り込むという件があり、お互いに労力の少なく出来る方法を考えてみたのでここに残しておく。前提として、システムばりばりなものではなく、デザインがメインだが、フォームがあるページや投稿系でシステムで出すべき一覧ページがあったりするようなサイトの場合です。

基本的な思想

基本的には、デザイナーさんが作ったhtmlファイルに極力プログラマ側で手を入れない。逆にプログラム上必要なタグ等を埋め込んだ場合には、そのマージ後のファイルを修正してもらう。
今回は、フレームワークにEthna、テンプレートエンジンにはSmartyを使ってあります。
最近、Smartyよくないという風潮ですが、プリフィルタなどのプラグイン機能は有用だと思います。

仕組みとして作ったもの

  • 1. .htmlファイルをエントリポイントにする
  • 2. Smartyのデリミタを変える
  • 3. Smartyのデリミタの種類増やす
  • 4. http<->httpsに絶対パスで書かなくても動くようにする
  • 5. 部品のincludeを出来るようにする
1. .htmlファイルをエントリポイントにする

デザイナーさんは、当然htmlファイルとしてデザインをします。それをシステム側に取り込むことになるのだが、その段階でファイルの階層がずれたり、URLが変わってしまうと、各ページからのリンクなども修正する必要が出てしまいます。
逆にページのURLをシステム側で決めた論理的なもの（物理ファイルが無いもの）にしていまうと、デザイン作成時にリンクが正しいかなどの確認が煩雑になります。


そこで、今回は、.htmlの拡張子が付いたファイルを phpとして動かし、さらにそれをエントリポイントとします。また同時に、テンプレートにもなるようにします。

例)
http://example.com/page/request_form.html
↓
request_form アクションが起動する

テンプレートとして使用する仕組みは、Ethnaの場合には、Viewの forward_path をいじってあげることで実現させています。
.htmlファイルを php として動かすには、以下のような .htaccess などで設定をしています。

#php settings
AddType application/x-httpd-php .html
AddType application/x-httpd-php .htm
<FilesMatch "\.html?$">
    php_value auto_prepend_file "/path/to/_action.php"
    # AcceptPathInfo Apache 2.0 only
    AcceptPathInfo Off
</FilesMatch>
2. Smartyのデリミタを変える

Smartyのデリミタは、次のようにしています。

<?php //色づけ
$smarty->left_delimiter = '<{';
$smarty->right_delimiter = '}>';

html内でこの 「 <{ 」 という書き方は通常出てくることはありえません。なぜなら、文章中で書きたいのならば、 「 &lt;{ 」 と書くべきで、htmlタグとしては、< の次には、htmlタグとして有効なアルファベットか、htmlコメント用の ! しか出てくることはありえません。


これは、以前こちらの記事でも書いたことがありました。
「Smartyのデリミタとescape - maru.cc@はてな」

3. Smartyのデリミタの種類増やす

2の「 <{ 」この形式のデリミタを使用した場合の弊害と出てくるのは、htmlタグ内の属性値にSmartyタグを入れたい場合に、htmlとしておかしな状態になってしまいます。

例)
<a href="sample.html?id=<{$id}>">link</a>
<input type="text" name="sample" value="<{$form.sample}>" />


これを回避するために、Smartyのデリミタの種類を増やしてみました。正確にはデリミタとして認識される文字列を増やしてみました。また、htmlタグ内で使うためにurlencodeをした文字列を使うようにしてみます。
今回採用した方法としては、次のようなルールです。
デリミタとして次の文字を追加

  • %3C%7B
  • %7D%3E

それぞれ 「 <{ 」 「 }> 」 を urlencodeしたものです。また、このタグ内は urldecodeされるようにしました。
実際に記述する場合には次のようになります。

例)
<a href="sample.html?id=%3C%7B%24id%7D%3E">link</a>
<input type="text" name="sample" value="%3C%7B%24form.sample%7D%3E" />

「$」は、urldecodeしてもそのままなので、次のように書いてもOK。

例)
<a href="sample.html?id=%3C%7B$id%7D%3E">link</a>
<input type="text" name="sample" value="%3C%7B$form.sample%7D%3E" />


これを有効にするには、以下のような Smartyのプリフィルタプラグインを使用します。

<?php
/**
 * Smartyプリフィルタプラグイン
 */
/**
 * タグ内の属性値等にSmartyタグを入れるための拡張
 *
 * <pre>
 * SmartyのデリミタのURLエンコード値の範囲内をurldecodeする
 * ex.)
 * left_delimiter = '<{'
 * right_delimiter = '}>'
 * <input type="text" name="sample" value="%3C%7B%24form.sample%7D%3E" />
 * ↓
 * <input type="text" name="sample" value="<{$form.sample}>" />
 * </pre>
 */
function smarty_prefilter_delimiter_urldecode($source, &$smarty)
{
    $pattern = sprintf('!(%s.*%s)!msueU'
        , preg_quote(urlencode($smarty->left_delimiter), '!')
        , preg_quote(urlencode($smarty->right_delimiter), '!')
        );
    $buf = preg_replace($pattern, "urldecode('\$1')", $source);
    return $buf;
}


このファイルを Smartyプラグインディレクトリとして登録したディレクトリ内に 「prefilter.delimiter_urldecode.php」というファイル名で保存し、Smartyの読み込みプラグインに登録します。

<?php //色づけ
$smarty->autoload_filters['pre'][] = 'delimiter_urldecode';


とりあえず、今回はこの程度で済ませましたが、if や foreach をhtmlコメント形式にしたデリミタ形式を追加するのもありだと思います。

4. http<->httpsに絶対パスで書かなくても動くようにする

htmlを作るうえで、環境依存になりがちなのが、http領域とSSL領域を行き来するリンクです。URLに http または https から書かねばならず、絶対パスになってしまうので環境依存になります。こちらも Smartyのプリフィルタを使用して置換処理をしてしまいます。
私の会社ではドキュメントルートは次のような名前を使用しています。

  • htdocs　　　<-http領域のドキュメントルート
  • htdocs.ssl　<- https領域のドキュメントルート

こちらをそれぞれ相対パスで書いてもらって置換する仕組みです。

例)
http://example.com/index.html -> https://example.com/form.html へのリンク
<a href="../htdocs.ssl/form.html">リンク</a>

https://example.com/sample1/page1.html -> http://example.com/sample2/page2.html へのリンク
<a href="../../htdocs/sample2/page2.html">リンク</a>


phpのコードは割愛しますが、上記のデリミタ置換と同様の形式です。実際に使用しているプリフィルタでは、htmlのタグと属性まで識別し、単なる文字列置換ではなく、aタグなどのタグとhrefなどの属性まで見るようにしています。

5. 部品のincludeを出来るようにする

htmlをデザインする時に、実際にはヘッダーやフッターなどは部品化して作成しているので、それをそのまま使えるようにします。
デザイン時点では部品化し、SSIのインクルードで確認などをして、こちらのシステムへの組み込みはそのSSIのタグのままテンプレートとして使用し、SSIのインクルードタグを Smartyのインクルードタグに置換するプリフィルタを作成しました。

例)
html上の記述
<!--#include virtual="/include/header.html" -->
↓置換後
<{include file="/path/to/include/header.html"}>


Smartyプリフィルタプラグイン

<?php
/**
 * Smartyプリフィルタプラグイン
 */
/**
 * SSI形式のincludeタグを認識させるための拡張
 *
 * <pre>
 * ex.)
 * <!--#include virtual="/include/header.html" -->
 * ↓
 * <{include file="/path/to/include/header.html"}>
 * </pre>
 */
function smarty_prefilter_ssiparts_include($source, &$smarty)
{
    $pattern = sprintf('/<!--#include +virtual *= *"\/([^"]+)" +-->/msuU'
        );
    $path = $_SERVER['DOCUMENT_ROOT'];
    $buf = preg_replace($pattern, "<{include file='{$path}/\$1'}>", $source);
    return $buf;
}


このファイルを Smartyプラグインディレクトリとして登録したディレクトリ内に 「prefilter.ssiparts_include.php」というファイル名で保存し、Smartyの読み込みプラグインに登録します。

<?php //色づけ
$smarty->autoload_filters['pre'][] = 'ssiparts_include';

最後に

これはあくまでも仕組みで吸収できるであろう部分のみなので、実際にはデザイナーさんが SSIで部品を分けてくれるかとか、マージ後の文字列を壊さないかなどの問題はありますし、意識をあわせる必要もあります。
今回、SSIタグ方式などは、元々は独自タグを書いてもらうつもりでしたが、ミーティング時にSSIで部品化するような話が出てきたのでその場で決めた仕様だったりします。
うまくいかない場面も出てくるとは思いますが、随時やり方をアップデートしていきたいと思います。


最近のphp界隈の人たちと話すと、テンプレートエンジンがどうこうという話がよく出てくると思います。いまどきSmartyも無いよねというのもよく聞きます。
確かに、システムバリバリの作りこんだ管理画面に、上記のような仕組みを導入しようとは思いません。そこは開発者が楽になるように作ればいいと思いますが、サイトのユーザ側はどうしてもデザインの要素がとても大きくなります。サイトにもよりますが。
その場合に、デザイナーさんはタグを理解してくれないとか、開発側はデザイン変更時に手をわずらわされたくないとか。。
どちらか一方に負担をかけるやり方ではなく、お互いが少しの努力でより良く楽になるような仕組みにしていければと常々考えたりしています。


で、Smartyの是非ですが、個人的には使い勝手がいいし、Ethnaのデフォルトテンプレートエンジンということで多用しています。
上記のような置換をさせたとして、プリフィルタであれば、Smartyのコンパイル時に1度だけ動くことになりますし。
Smartyの話がでてきた時に気になるのは、このような Smartyプラグインをいろいろそろえてこその Smartyだと思いますので、タグ形式などだけで話すのは少し不毛な気がします。

Ethnaのコミッタになりました

Ethna

Ethnaコミッタのmumumuさんに突然声をかけてもらって、Ethnaのコミッタになりました。

権限を分散させることにした。動ける人が一人であってはいけない。それがプロジェクトが生き残る力になる。チェックする眼を増やすこと。それもプロジェクトの利益になる。それがOSSというものだ。
mumumuの日記: Commit Bit（2）

とのことでした。
びっくりした。



プロジェクトメンバーに名前が出てる。あたりまえだけど。
メンバーリスト - Ethna - SourceForge.JP



というわけで、できる範囲でできる事をしていきたいと思います。

設計勉強会に参加してきた（かなり前に）

勉強会

id:shimookaさん企画された設計勉強会に参加してきました。
「設計勉強会 - events.php.gr.jp」
ぎりぎりまで会社を出れず、時間をちょっとすぎたぐらいに着きました。

WEBアプリケーションにおける設計とは？

PHPユーザ会
id:yandoさん
猫好き　ゴルフ好き　CakePHP好き
10/25にCakePHPカンファレンスがある（すいません！もう終わってる。。）

PHPerにとっての設計
いろいろな設計がある
基本　外部　内部　詳細

ぐぐっても定義が出てこない
なにをもって定義するか　基本と外部がいっしょとか

phpが通信ならばwebアプリケーション
ほぼLAMPなアーキテクチャ
超厳密なトランザクション管理もない

PHPの視点からみるときまている
11万月とかもない

詳細設計が話す内容ではないか
チーム体制とかは聞きたくないだろう

詳細設計のフェーズをコーディング前にとる
いきなりコーディングすると問題がいろいろある

使用の理解ずれ
適切な処理単位
想定される処理量、処理方式
　バッチ処理にするなどの対策
コーディング後に修正が大変
　FWをどこまで使うか　プロペル<->SQL
　トランザクションの管理ポリシー
　命名規則
　　あとからモジュール名変更とか記憶にない


個人的に気にする点
認証の有無　SSL　セッションの単位
　ちゃんとしないときもいモジュールができる
　1つのモジュールでまたいで変なことをすると気持ち悪くなる
　画面単位ではなくて　目に見えないところ
複雑すぎる処理はシンプルに　ifのネスト3段階になるとつらい　しないように
　人間が読めるように
表示に特化した処理はviewに
　タグがactionに出ないように
再利用できそうな処理をライブラリ化する


未来のために
リスクを避けるために固執過ぎると膠着状態になる
ユニットテストとかは絶対にやったほうが
　ユニットテストやったほうぎい？　全員
　ユニットテストやってる？　いない

ORまっぱはつかったほうが良い

Smartyはやめたほうがいい
APCは絶対使ったほうがいい
バージョン管理はひつよう
本番環境でのソース編集が必要なのはへん

ZENDのカンファレンスでも話があった

当たり前なことだけど、当たり前のことをしっかりやったほうがいい



コードキャッシュの話
月曜のPHP勉強会で話しますので　続きは月曜日に


Smartyを入れただけで遅くなる事実
いまから使うのはしなくていい
Smartyのタグがあってうれしい人はいる？


質疑応答では、SmartyによりもPHPの方がみづらいのではないか？という意見もあったが。
あんまりSmartyを用意したからデザイナーでということはないのでは。
Smartyにしたからデザイナーができるというのはできていないのでは。
エンジニアがテンプレートも書く。

Ethna的なActionとViewな何か

id:sotarokさん
「設計勉強会で発表してきました＋メモ＋資料 - 肉とご飯と甘いもの @ sotarok」

haltさんに喧嘩を売られた気がするので話すとか。
設計に長けていないが　ポリシーを話したい
元events.php.gr.jpよりはポリシーがある


ライトウェイトなMVC


図がよかったです。
AppManagerとかAppObjectとか使ってない
Ethnaのpreforwrdの使い方とか。

Ethnaの使い方講座になってるｗ


Open PEAR Serverをやっている
openpearコマンドとか。
すでにリリースしています！＞http://openpear.org/


MVCとは何か。おまえらMVCわからずにフレームワーク使うな

haltさん
MVCとは何か。
おまえらMVCがわからずにフレームワークを使うな


Mojaviの場合とかから始まって過去のフレームワークの話。
私は知らない頃の話なので面白かった。


Ethna
テンプレートにSmartyのforeachがあって、viewクラスにもDBから取得のロジックがある

viewクラスって必要なくない？
という話


ここまで

話を聞きながらメモをしていたのだが、　PCの入れ替えなどで埋もれてしまっていました。

第2回設計勉強会を聞いてきました

勉強会

「第2回設計勉強会 - events.php.gr.jp」
会社から走ってなんとか始まる前に着けました。

「クイズ研」開発上の設計判断とその結果

twkさん
クイズ研というサービスを作ったときのはなし
ZFをつかって作ったそうです。
その後に請負で作ったものもある　新規だけでなく


レイヤ構成
　コントローラー
　DAO
　テーブルアクセスクラス
　MySQL

DAO
　modelsフォルダの中

auto_loadを使う


面白いと思ったのは、Smartyのデリミタが

<?//{
}?>

IDEでうまくいくかと思って試したが、不評だしうまくいかなかったので、その後使ってないそうですw


DAOでラップすればSQL書いてもいいのでは？

Smartyのメリット
短くかけることが多い htmlがきれいに見れる
自動エスケープはOn

それ以降ではSmarty未使用とのことw


Viewにロジックはあり？なし？
というのが疑問だとか。
Viewはテンプレートというわけではないので、ありだよという突っ込みが周りからありました。


レイヤー切り分けてる？

はたさん


レイヤー使ってる？
レイヤーパターン
依存関係が一方向


Webフレームワーク→サービスレイヤ→Dao
レイヤーごとの役割


入出料組み替え　ビューの構築
画面ロジックの構築　サービス例やへの引き継ぐ値の構築


サービスレイヤ
　ドメインロジックを構築
　トランザクション
　ビジネスロジックのためのインターフェース

ドメインレイヤ
　データベースとのコミュニケーション
　いろいろあるので大丈夫


MVCもアーキテクチャパターン

WebアプリケーションにおけるMVCは一レイヤ

シナリオ単位でレイヤをきっている
レイヤは規約
レイヤを超えてアクセスしない


DXO
レイヤ間の依存をなくすための
Data eXchange Object



画面ロジック　ドメインロジックの２パターン
業務ロジックはロジック


画面とDBが１対１
ほぼプレゼンテーションロジックに向いてる


基本３つのレイヤー
Action Dao Service

各レイヤーは依存を作らない
　DTOは作る
　readOnlyのオブジェクトを返す
　ViewにはDTOを持っていくこともある


Mockの実装とかを楽になるように
インターフェースを書くようにする


レイヤー単位のUnitテストがかけるので楽
　見通しがつきやすい
　Serviceレイヤーより後ろはFWと切り離しができる＝依存が少なくなる＝テストしやすい


DB Loggerなどの依存関係の解決が難しい


S2Daoが自分で使うには大きすぎて使えないとのことですw
新しいものを作っているそうなので期待。


レイヤー分けをしてどのようになるのかがわかりにくかった
依存を減らして、テストが楽になるというのは興味がある。


ロジックのclassをシンプルにし、テストをしやすいようにというのは参考になりました。
レイヤ指向？というのは始めて知った。


結局Webのアーキテクチャーって？

id:kunit さん

レイヤーとMVCは違う　合わない
MVCは密結合になる

コミュニティに還元すべき

実際に動くコードで見比べたり、それをもとに話す必要がある。
そのためのひな形としてPhwittrとか。



弊社サービスの場合の設計

id:shimooka さん
モビログというサービスについてのデモ。
実際にうちの会社で使っているのだが、モバイル用としてはとても高機能でいい。


で、それのリニューアルで実際に書いているコードやテストを実際に見せてもらう。
PHPUnitを使っているとのことでした、
その中ですばらしいと思ったのは、コードのテストカバレッジ率が出るのと、実際にコードのどこをカバーしているか、逆にテストできていないかをビジュアルで見ることができていました。これはすばらしい。
PHPUnit3の機能らしいので、ぜひ使ってみたい。
http://www.phpunit.de/pocket_guide/3.0/ja/code-coverage-analysis.html

懇親会

なんか熱くいろいろ話していました。
会場提供してくださった、ディノの噂のビールサーバを使えましたしね！

最後に

id:shimookaさん、第一回に続き第二回の設計勉強会の主催おつかれさまでした。
会場提供してくださった、ディノさんありがとうございます。
懇親会の幹事をしてくださった、LINDさんありがとうございます。


いま、一番興味のあるテストやフレームワークの思想とかそのあたりで、いろいろ刺激を受けました。