さて今回は、1.3系で・・しかも出尽くされていると思いますがViewキャッシュ導入について紹介したいと思います。
いろいろな方がこちらは紹介されていますが、私でもできるヨ！ってことで生暖かく見てください。
頑張って図つけたわ。。これが一番時間かかったとか・・・・。

・登録者向けのサービスだが、ログイン前にランディングページなどの静的なページを多用している
・できるだけ、ウェブサーバーへの負荷を軽減したい

などの時にぜひ。

レシピ：cake1.3、 https://github.com/mcurry/html_cacheからダウンロードしてきた一式

手順その１：

https://github.com/mcurry/html_cache　からファイルをダウンロードしてapp/plugins/html_cache/の下につっこむ。

手順その２：
App::import(‘core’, ‘File’); をapp_controller.phpのbeforeFilterに記述する（これ重要です。忘れてすごい悩んだ・・）
特定のコントローラーだけに処理をさせたい場合は、該当するcontrollerのbeforeFilterに記述が望ましいでしょう。

手順その３：webroot/cache配下に静的に出力したいファイルのパスでディレクトリをつくる。app/webroot/cache/controller名/action名/のような。

手順その４：
３で作成したディレクトリにアクセス権限をつける。実際にここに静的なHTMLファイルが作成されます。

手順その５：
静的表示をしたいコントローラー、のアクションに、

$this->helpers[] = ‘HtmlCache.HtmlCache’;

を追記する。
※妙な怒りのデバッグが入っていますがおきになさらずに。ちゃんと表示されます。

これは、３の手順で作成したディレクトリのパスにcontroller,actionが一致している必要があります。

手順その６：
webroot直下にある/htaccessを表1.のように変更する（簡単に言うと、webroot/cache配下に該当のファイルがある場合にはそちらを優先的参照する。ない場合は通常通りフレームワークのルールに則り、/controller/actionへ飛ぶ。）

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_METHOD} ^GET$ #追加部分
RewriteCond %{DOCUMENT_ROOT}/cache/$1/index.html -f #追加部分
RewriteRule ^(.*)$ /cache/$1/index.html [L]　　#追加部分
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]
</IfModule>

手順その７：
美味しくいただく。　さあ該当ページにアクセスしてみましょう。ファイルが作成されない場合はパーミッションの確認をしてください。
３で作られたディレクトリにファイルがつくられていますか？日付を見てみてくださいね。
この場合、controllerも通らないので不必要なロードがされないので結構表示速度を体感できるのではないかと思います。
（コンテンツにもよるでしょうが）

試しに削除してもう一度作成してみましょう。【やったー！】
注意すべきことはctpファイルの中身に変更が合った場合などは、

こちらにあるキャッシュを一度削除しないと新しいファイルが作成されません。

そのため頻繁に変更するファイルに関してはあまり向かないかもしれませんが、キャッシュで表示する方が
明らかに表示速度は上昇しますので、お手軽にできますし皆さん、試してみてはいかがでしょうか。

さて、明日はおなじみ@mon_satさんです。よろしくおねがいしまーす！

なので、paginateの導入も含めてメモしときます。

※試行錯誤なんで、自己責任でよろしくおねがいします＞＜

1.2.2使っているので、コンソールでとりあえず

する。そうすると、コンソールで「いれちゃうぜ？」てきいてくるので、はいyて答える。

そうすると・・・playインストール場所/modulre/paginate-0.11

という構成になり、そこにモジュールが展開される。

そのあと、

conf/dependencies.ymlに

~ play -> paginate 0.11
これを追記して、さらに
conf/application.confに
# Import the pagenate module
module.paginate=${play.path}/modules/paginate-0.11
こんな感じで、play再起動。起動時に、
Module paginate is available (/home/yashiro/play-1.2.2/modules/paginate-0.11)
とかいうログが見えると、無事paginateモジュールが読み込まれています。
さて、そのモジュールの中に、htmlが入っていて、（playの雛形みたいな）paginateに対してどういう記述をするか
が書かれているControls.htmlをいうソースを探し出します( paginate-0.11/app/views/にありました）。
それをコピーして、app/views/paginate/Controls.htmlという構成にします。
（やってることはcakephpで、helperを自分のappの配下にもってきて変更していることにそっくり。）

それでそのファイルをこんな感じで修正してみました。そしたらデモで見えるようなpaginateが表示されたよ！

(実際はpaginateを表示させるところまで、これ以外にもいろいろ道のりがあったんですが・・それは割愛）

app/views/paginate/Controls.html

%{
int __firstPage = 1;
int __currentPage = _items.pageNumber;
int __pagesDisplayed = _items.pagesDisplayed;
int __pagesBeforeMiddle = __pagesDisplayed / 2;
int __maxPage = _items.pageCount;
if (__currentPage > (__pagesDisplayed / 2)) {
	__firstPage = __currentPage - __pagesBeforeMiddle;
}
int __lastPage = __currentPage + (__pagesDisplayed - __pagesBeforeMiddle - 1);
if (__currentPage < (__pagesDisplayed - __pagesBeforeMiddle)) {
	__lastPage = __pagesDisplayed;
}
if (__lastPage > __maxPage) {
	__lastPage = __maxPage;
}
boolean __hasPrev = _items.hasPreviousPage;
boolean __hasNext = _items.hasNextPage;
String __firstURL = __hasPrev ? _items.getCallbackURL(1) : "#";
String __prevURL = __hasPrev ? _items.getCallbackURL(__currentPage-1) : "#";
String __nextURL = __hasNext ? _items.getCallbackURL(__currentPage+1) : "#";
String __lastURL = __hasNext ? _items.getCallbackURL(__maxPage) : "#";
%}
<div class="pagination">
	<ul>
%{ if (_items.boundaryControlsEnabled) { %}
		<li class="${__currentPage == 1 ? 'disabled' : 'first'}"><a href="${__firstURL}">&{'play-paginate.first'}</a></li>
%{ } %}
		<li class="${__hasPrev ? 'previous' : 'disabled'}"><a href="${__prevURL}">&{'play-paginate.prev'}</a></li>
%{
for (__idx = __firstPage; __idx <= __lastPage; __idx++) {
boolean __active = __currentPage == __idx;
%}
		<li class="${__active ? 'active' : 'inactive'}"><a href="${_items.getCallbackURL(__idx)}">${__idx}</a></li>
%{
}
%}
		<li class="${__hasNext ? '' : 'disabled'}"><a href="${__nextURL}">&{'play-paginate.next'}</a></li>
%{ if (_items.boundaryControlsEnabled) { %}
		<li class="${__currentPage == __maxPage ? 'disabled' : ''} next"><a href="${__lastURL}">&{'play-paginate.last'}</a></li>
%{ } %}
	</ul>
</div>
<br style="clear:both;"/>

まあここまではよかったんだけど、lastページになると、PreviousとNextのあいだのページ数が一個減るという謎の

現象に・・まあこれは次回でもどうにか修正することにしましょう。

※１０年ぶりにJavaとか見たら、「アノテーション」とかいう謎の識別子がついていて時代を感じた。

Shellスクリプトもいろいろ面白いでつね。

#!/bin/sh
#DAYは数字で曜日。
DAY=`date '+%w'`
WORK_DIR=バックアップするディレクトリ
FILE_NAME=dump_$DAY
BACKUP_DIR=/tmp/
USER=DBのユーザ名
PASS=DBのパスワード
DB_NAME=データベース名

#バックアップディレクトリに移動
cd $BACKUP_DIR
#バックアップディレクトリがなかったら
if [ ! -d $WORK_DIR ]; then

	#ディレクトリを作成する
	mkdir $WORK_DIR
fi

#そのディレクトリに入る
cd $WORK_DIR
#事前にあったファイルは全部消す
rm ./*

#データベース内にあるテーブルリストを作成し、個別にテーブルのダンプデータを作成する
#-eはその後コマンドを実行するというオプション。
#-Bは余計な表示をせずに一覧を出力させる。
#-Nは一番上の見出しを削除する
for TABLENAME in ` mysql -u $USER -p$PASS -B -N -e 'show tables' $DB_NAME`
do
	#echo $TABLENAME
	mysqldump --opt -c -u $USER -p$PASS -x $DB_NAME $TABLENAME > $TABLENAME.sql
done

#移動する
cd $BACKUP_DIR

#該当する日付のディレクトリをまるごと圧縮する
tar -czf $DB_NAME$DAY.tar.gz $WORK_DIR

前提条件

１．A_controllerでpaginateしている
２．paginate対象のモデル(User)には色々なモデルが関連付けられているが、その1部であるHogehogeというモデルをLEFTJOINではなく、INNERJOINで連結したいので一度unbindする
３．このメソッドが呼ばれる前にapp_controllerのbeforeFilter()にUserモデルで検索をかけている箇所がある。そこはContainableBehaviorが使われている

という前提でした。

１．A_controllerのpaginateの箇所はこんなかんじ。

$this->User->unbindModel(array('belongsTo'=>array('Hogehoge')), false);//第2引数をfalseにすることでモデルの関連性を維持させる

			'joins'=>array(
				array(
					'type'	=>'INNER',
					'fields'=>array('Hogehoge.name'),
					'table'=>'`Hogehoges`',
					'alias'=>'`Hogehoge`',
					'conditions'=>array(
						'Hogehoge.id = Hogehoge.user_id',
					),
				),
			),
//このあとpaginate実行

でハッピー！　にならなかった・・・というお話。

まず、unbindModelの第2引数にfalseを渡すことで永続的にモデルのアソシエーション状態を保持してる、つもり。
ブログ記事でよく見かけますが、ここにfalseを設定しないと、paginateでは
・件数
・欲しいレコード
を段階的に取得するため、2回目のクエリでアソシエーションがもどってしまうという。という記事がじゃんじゃん、でてくる。

だがしかし。

falseにしてるのにどーやってもあーやってもHogehogeテーブルがLEFTJOINされ、上記のINNERJOINのHogehogeテーブルまでくっついてくるので「 Not unique table/alias: ‘Hogehoge’ 」って怒られます。憤ります。ぷるぷる。別名とか別にLEFTJOINでもいいなとか色々選択肢はあったのですが、最近「ソースコードよめよ」なので一念発起してソースの旅に出てみることにしました。cakeフォルダのなかにダイヴします。

まずコアソースのcontroller.phpでpaginate()をあさります。ださいこと極まりないですが、ここでかたっぱしからdebug($object->belongsTo);を出力して、どうやら

$count = $object->find('count', array_merge($parameters, $extra));

ここの前後で、belongsToの中身が、もともとのモデルにセットされているアソシエーションにもどってしまうことが分りました。つまり、falseにしているにも関わらず件数取得時にアソシエーションがリセットされていることになります。なので、こんどはmodel::find()をあさります。

すると、今度はmodel::findにある

$results = $this->__filterResults($results);

この箇所でbelongsToの内容が変化してしまうことがわかりました。そんな感じでソースをぐるぐるを追いかけていったところ結局、ここではcallback関数がよばれていて、model_behavior.phpにいき、

$this->Behaviors->trigger($this, 'afterFind', array($results, $primary), array('modParams' => true));

のようなtriggerメソッドから、afterFind()がよばれていることに。結論からいうと、app_controller.phpで

３。のメソッドが実行される
→ここで、Userモデルの変数に__backAssociationという、いわば「モデルの既存アソシエーション」がバックアップのような意味合いでセットされる。

次に、paginate処理を行う
→ここで、paginateのINNERJOINを実行したいためunbindする(INNER JOIN対象のモデルを、Userモデルから切り離す）
→paginate実行
内部処理：カウントを取得　　→ここで、カウントを取得。この時点はアソシエーションはunbind状態が保持されている
→count取得時のfindのafterFindが実行。その際、既にUserモデルにセットされている__backAssociationの値を参照しておりここに値が入っていると明示的にモデルのアソシエーションをデフォルトに戻してしまう

→実際のレコードを検出(findが実行)
→既にアソシエーションがもどっているため、unbindされたモデルなんぞは無視され、同じモデルが2回JOINされる有様。

なんで、model_behavior.phpのafterFindなのかというと、app_controller側で呼び出したメソッド内でUserモデルにビヘイビアがセットされるため、paginateではBehaviorは使っていないにもかかわらずここのafterFindが呼ばれる・・・らしい。ここだけはちょっとあやふや。もし「ここおかしいよ」って思われる方がいらっしゃったらご指摘いただけると。

対処方法：app_conrtollerのbeforeFilter()のクエリをContainableBehaviorを使わずに普通にjoinした。
とりあえずこの対応方法で行ったのですが…根本的ではないですね。
そもそも、事前に実行されるメソッドで利用したモデルの構成は引き継がれるという当たり前なことに気が付かず、　app_controllerにこのメソッドを追加する前まではpaginate処理が動作していたので非常にデバッグに時間がかかってしまいました。
一度Userモデルを使っているわけですから、そういう意味では原因がわかって「そりゃそうだな・・・」という気持ちになったのも事実です・・が

事前にＡモデルをContainableBehaviorを使って実行し、そのまま続けてＡモデルのモデル構成を変更（bind/unbind)しpaginateを行った場合に第2引数のfalseは役に立たない　という結論で・・・よろしいか？
こういう状況って皆さんあまりない・・かな。不具合とはいえないかもなんですが、ちょっと気になったのでネタにしてみました。　鼻の黒い人にこんな記事を見つけてもらったのですが同じ事をいってる・・かな。そう考えると、同じモデルのメソッドを別々のところで呼び出しているのもどうなのかなーって事もあるのかもですが、

ContainableBehaviorとpaginateの相性はそこまでウフフな関係にはいたっていないということでしょうか。
アソシエーションを密接にしておくと、思わぬところで意識していなかったモデルの姿形がかわっとる！という事があるかもしれないですね・・

ＤＢ上で登録したテンプレートなる文書のデータを、subjectだけ一覧で見せたい。
そんで、その一覧のsubjectをクリックしたら、テンプレートの内容をtextareaにセットしたい。

…たったこれだけ。
やってみたことはリンククリック時にわざわざＤＢ通信するのもなんなので…ちょっとダサいけど、ページ出力時にテンプレートの内容はＤＩＶで区切ってどっかに出力させて、かつ表示させない(display=none)にして、リンククリックしたらそのＤＩＶの中身をテキストエリアにセットする、という流れ。

ところが、Ｃｈｒｏｍｅだとちゃんと見えるのにＩＥ（７）だと、テンプレート内の改行が全部、すっ飛ばされてしまう！
で、ググると出てくる、出てくる。そもそもinnerHTMLには適用されないだの、textareaがＵＮＫＯだとか、ＩＥ・・・？とか色々でてくるんですけど、これ！っていう情報が出てこない。なんつーか文字コードと混同してる（私が）感じで情報が切り分けられず、phpで文字コードを変換してみたりとか色々したけどもうだめびーるのみたいしさいきん体組成系かってふとったしビールのみたいし。

で、ＤＩＶタグなのがいけないのかと思ってたので、仕方ないのでinputタグで出力し、それを見せない、みたいなことをやってみたんだけど、どうにもこうにもダメ。text()でやるとうまくいった、とかいろいろあったんだけどもうだめぽ…と思ったんですが最終的に一番楽そうな手段が見つかったので、備忘録的にメモ。これが最適手段ではないと思いますが、もし他の方法をご存知の方がいらしたら「っへ！こんなのもあるでよ！」って教えてくれるとありがたい。

結論からいうとですね、ＤＩＶタグではなくて、テンプレートの内容をあらかじめtextareaに書き出しました。そして上記のようにdispayをnoneにして非表示にし、この値をjQueryで言うところのval()で取得し、セットもval()で行いました。そうするとＩＥだろうがＣｈｒｏｍｅだろうが、改行がきちんと判断されるようになりましたとさ。


$(document).ready(function() {
// bind 'Form' and provide a simple callback function
$(".template").click(function(event){
$('.comment').val($("textarea.setText" + $(this).attr('id')).val());
return false;
});
});

こんなかんじで、セットする元のテンプレート内容は

	if(isset($document)){
		//改行処理があるため、セットする要素と同じtextareaで対処する
	    foreach($template as $key=>$value) {
			echo "<textarea style='display:none' class='setText{$value['Template']['id']}'>";
	    	echo $value['Template']['content'];
			echo '</textarea>';
	    	
	    }
	}

※２１日はCakeAdvent2010 なんで最近はまったcontainableとunbindのくだりを書く予定です。よろしくお願いします。

びふぉあ

あふたー

ここで今回私が社内で悪戦苦闘したVirtualBoxのインポートと、Gitの接続時にしくじったことをメモ書き。

Virtual Boxのインポートに失敗
自宅で構築したVirtual BoxのVMイメージをエクスポートし、会社でインポートしようとすると途中で以下のようなエラーがでて中断する。　KU　SO　GA!

The vm session was closed before any attempt to power it on.

ガクガク。意味分らないから英語でも検索すると
このサイトがでてきたので、VirtualBoxのVMの設定より、起動時のストレージにある、CDROMだのFDだののチェックを外したら読み込みだした！
（実は鼻の黒い人が「おれインポートって成功したことない・・」とかいうので、半分駄目元ではあったけど、インポートできると設定情報が引き継がれるから楽なんだよね・・・・。と結構粘着して調べていた。）

TortoiseGitで　git cloneできない。

次に、社内で今までSVNをつかっていた関係で、TortoiseGitをいれたら設定情報とかかぶるんじゃねえ？とおもっていたけど、とりあえず、秘密鍵作って外部リポジトリへ接続（git clone)を試みる。ガッ！

いみわからんし・・・。これをてっきりTortoiseSVNのせいだと疑っていた（SVNは社内サーバのリポジトリにアクセスしていたので）接続時にはTortoiseGitはplink.exeというインストール時にデフォルトで設定されているツールでSSH接続を試みるわけだが、そこを直接クリックしてもダイアログがでて、192.168.56.XXXのユーザ名をいれてください　みたいなこといわれる！これ結局3日間なやんだ・・・。

結果として、TortoiseSVNは一切関係なくて、2chのここにモロ、回答がかいてあった！！
TortoiseGitからgit cloneしようとしたときには既にインストールしてたputty.exeのdefault settingという接続情報が最も優先されるらしい。速攻でここのホスト名をぶち消した！そしたらちゃんと指定したURLにアクセスしたお！かーちゃん、やったよ！

すんごいくだらないかもしれないことだけど、もし、同じ事で迷路に入ってしまった人がいた時に何かの助けになるかもしれないので、一応メモ。

で、会社とは別に1.3系で開発をしているのですが、なんていうか、
・今までしらなかったのか！

みたいな事があります、あります。特に1.3系に特化した内容でもないので、「うわこいつ…いまさらこんなこといってんの？」的な生暖かい目でみてください。

1．モデルはチェーンできんだぞ？しってた？

Aモデルにアソシエーションを張っている場合それらのモデル（たとえばB)は、外部呼出しをせずともチェーン形式で呼び出しが可能。

たとえばコントローラー側では
$this->A->B->findAll();
等が可能。もちろんBのデータを全部取って来れます。（hasOneでもhasManyでもbelongsToでも）
※今までusesにいれるとか、Class::registryしてました……。
BがCとアソシエーションはっていれば、もちろん
Aのコントローラーから

$this->A->B->C->find();

そうなってくると。ありそうなのはMailテーブルにfromとtoというフィールドを用意し、両方、ユーザIDが入ってるような場合は当然、fromとtoにbelongsToで設定したいところです。例として名前はFromUser,ToUserという名前にしてみます。

この場合、たとえば送信元のデータを取ってきたい場合はMailコントローラーで呼び出す場合

$this->Mail->FromUser->getDetail();

condtions =array(
 $this->alias.'.id' => $id ,
)

みたいな事をいわれていまして・・・。で、後ほどエントリしようと思っていますが、muninがいいからmuninにすれば。といわれてmuninというパッケージをインストールして、ジっとながめる。ということを日々やっとります。muninのインストールについては結構いろんなところで情報があるので、そちらを参考にしていただいたほうがよいかもしれず。
今回のエントリは

っつーことでお知らせメール機能です。

閾値メール設定
/etc/muni/の中のmunin.confに下記のように追加（加筆したところは#でコメントをいれています。）

#送信したいメールアドレスを、[email]というグループに関連づける（下記はメールアドレスまで一行つながりです）
contact.email.command mail -s "Munin ${var:group}::${var:host}" hogehoge@xxx.vo.jp
#以下の行はmuninで監視しているプラグインの情報を個別にメールでおくるかの設定。1にすると７通とかメールくるからコメントアウト。
#contact.email.max_messages 1
#以下一行はcriticalなものだけを送信対象とする
contact.email.always_send critical
#[email]グループに対してメールを送る
contacts email
# Drop somejuser@fnord.comm and anotheruser@blibb.comm an email everytime
# something changes (OK -> WARNING, CRITICAL -> OK, etc)
#contact.someuser.command mail -s "Munin notification" somejuser@fnord.comm
#contact.anotheruser.command mail -s "Munin notification" anotheruser@blibb.comm
#
# For those with Nagios, the following might come in handy. In addition,
# the services must be defined in the Nagios server as well.
#contact.nagios.command /usr/sbin/send_nsca -H nagios.host.com -c /etc/send_nsca.cfg
# a simple host tree
[localhost]
address 127.0.0.1
use_node_name yes
#プロセス数が８０に達した時点でcriticalとみなす（メール送信がされるトリガ）
#下記設定は[localhost]の中で設定すること。
processes.processes.critical 80


で、munin-node再起動してじっと５分まつ。
上記はあくまでもプロセスの監視なので、フィールドやプラグインの名前はそれぞれ閾値を設定したい対象によって異なります。で、これだとmuninはグラフ描画のために５分間隔でデータを取りにいくので、プロセス数が８０になったら５分おきにメールがきてしまうｗｗｗｗｗこれをどうにかしないといけないのであった。各パラメーターの参照はhttp://castor.s26.xrea.com/blog/2007/10/19
とかこちらが非常に参考になりました。
むーん、このテーマだとコードが改行されてしまうな。見づらいのでどうにかしないと。

さて、発表は1.3ベースだったのですが、現在私が使用しているのは1.2。ですが将来的に新しいサービスの実装も控えていて、その際は100％間違いなく1.3であることが予想されるので興味深くお話を聞かせていただきました。また、私自身が勉強会の主催をさせていただいているKtai Libraryは新しいバージョンでどんどん進化しているようで、これも楽しみの一つでした。

印象に残ったセッションとしては

あたりがヒットで、谷井さんは別の勉強会でもご一緒したことがあったものの、「ついったー君」を作った人なのか！と妙に感動してしまいましたｗそれと

こちらの@hiromi2424さんはtwitterでも大変お世話になっていて、ひそかに「すごい人なんだろうな・・・」と思っていたのですが勉強会中のタイムラインの流れで「ああ、やっぱりすごい人なんだな」と妙に納得した次第でしたｗ懇親会では帰りがけに声をかけていただき、とってもうれしかったでっす！

そして、実は楽しみにはしていたのですが、 @nano_eightさんの発表で、jQueryの話の延長でFlexigridを利用しており、かつプラグイン化までされているという事実がががががが。実は先日、業務でcakephpサイトにFlexigridを導入し、導入したまでは良かったのですが「どうせここまでできたんだからこういう風にして」とかリクエストされて、「いやこれ、元からこういう機能だし・・」とうまく言い訳ができなかった私はこれまたtwitter経由と@Hampomさんの力を借りて機能をつけた、という背景があり。大分苦戦しました。苦戦したのはほとんどjQueryの部分だったのですが・・・。まあjQueryを学ぶ良い機会だったと思います。（ちなみにこちらを通勤時間の行き２０分で、５日間みっちり読みましたｗ）php側の処理は非常にお粗末な作りで実装してしまっているので、プラグインを使うことで共通化でき、コードの見通しが良くなるのではないかと期待しています。

Flexigridはおなじみだとは思いますがこちらをごらんになっていただければよいかと思います。単一ではありますが検索、テーブル一覧表示、表示カラムの追加・削除・ソート機能、改ページ機能・列入れ替えなどが非常に視覚的にできる（リンクの一番下のサンプルで、虫眼鏡マークとか色々いじってもらえるとわかるかと思いますが）のでちょっとした一覧でしたら導入しただけで「なんだかしやわせ」になるわけです。オプションも結構豊富ですしフックメソッドの実装も可能です。@nano_eightのプラググイン化されているものが簡単に呼び出せれば既存の一覧もこの形にすることが今よりも可能になるのでは、と非常に期待しています。こちらに関しては自分も動かしてみようと思っています。

懇親会も非常に楽しく、cakeの話題からテレホーダイの話や英語を勉強するには…！など幅広く、またエンジニアとしてのモチベーションを維持するためのエッセンスを得られたと思います。「ウェブサービス楽しくつくろうよ！」と声を大きくして発言する方がいて「そうだよね、やっぱ作って発表だよね」なんて思ったりして。当たり前のことですがやっぱり前向きな人の輪の中にいれば、人間おのずと前向きになるんじゃないでしょうか。そして私（や他の誰か）が会社のエンジニアに勉強会で得たエッセンスを伝播させていく。勉強会は決して会が終わってそこで終端ではないんですよね。むしろそこから情報の広がりがあるんじゃないかと感じます。

私は、業界自体は１０年近くありますが、ブランクもあり、php自体は１年ちょっと、cakephpも同じくらいの経験値です。当時は職場ではphpの案件はなく、プログラムだけを書き、非同期通信やウェブサービスのいまどき　をほとんど知らずに仕事をしてきました。これはまずいと転職してちょっと職種が変わっただけで、日々書籍をあさり、検索をし、トライ＆エラー、果ては自身のパートナーに教えてもらう夜もあります。角度がちょっと違っただけで吸収しなくてはいけない量が倍増しました。それは私が選んですきでやっていることですが、一人きりでは行き詰る日もあります。そういう意味で勉強会やtwitterというつながりは非常に強力で、近しい場所に目標というか、自身が成長したらこうなれるのかな、という方々がいるのは励みになります。なんていうか「いい時代に生まれたんだなあ」という気がしますｗ

※現在Ktai Library勉強会の日程を調整していますが土曜日は会議室がどこも一杯なんだぜ…！「ここあいてるよ」などのコメントお待ちしています。もうちょっと色々書きたかったですが、本日はここまで。

だったわけですが。

テーブルの構造上＋データの出力上、unionすることになり、まあそれもクエリ自由にかけますから関係ないですよね、と思ってunionしまして出力してうへへへよかったね。ということで落ち着いたのですが、数日後、unionせずにデータを取得することができることが判明し。クエリを書き直したんですね。でunion消したと。そうしましたら。

おいおい、データがとれないくなったよ^^;実際のクエリをコンソールなりで実行するとデータが取れるわけだが、フレームワーク上では今までとどうも配列の構造がちがうんじゃね？と思って返却されたデータをみておっさん驚いた。全てのデータ（フィールド）が、取得元のテーブルのキー配列に入れ子になっておる。アッ！つまりですね…今まで[0]['field1']で取得できていたデータが全て[0]['table']['field1']という構造になってるよ！えー！というお話。unionしているクエリは全て別名で as ‘hogehoge’と指定しており、そこにテーブル名の記述はないので、すっかり「？？どうして？」とてんぱったというお話。今考えると「…まあそうだね」という結論ですけれども。

今回のケースはunionが肝で、データとして別のテーブルから、エイリアスとして同じ名前で設定したフィールドを取得しているため、「どこのテーブルから」という情報が識別できないので、取得時に[0]['field1']という形でデータを帰さざるを得なかったわけですが、unionを消したことで取得元のテーブルが明確になり、[0]['table']['field1']という構造で返却されました、ということでした。で、色々調べてみたんですけど、こちらに1.1系の話がのっていて気になったので自分も同様のソースを参照してみたところcakeの中のソースは同じでした。

というわけで、クエリをじかに書いていて、フィールド名のキーだけでいいんじゃゴルァ！という人はunionつかって空っぽのデータとくっつければいいよって、これちょっと乱暴じゃないか。いや他に良い策があればそれを実行したいのですが。統計情報とかで複雑なクエリを組んだりする場合、あちこちのテーブルからデータを取ってくることって多いと思うんですよね。なもんで、別にモデル名でいちいち判断してくれずに階層を浅くしてほしいな…と思えるシーンもあるんじゃないでしょうか。いちいちテーブルのキー情報で個別に判断するのはちょっとな…と思ったのでした。1.2でのお話です。こんな悩みに遭遇した方いらっしゃいますでしょうか…。

さてさてパフォーマンスチューニングやら、jQueryやら色々やってるわけですがブログが追いつかず悲しい…。最近はflexigridなんか使ってワーワーって感じでやっとります。今これ読んでます。今年は雑種な感じでなんでもあり、でOS本だのサーバ本だのフレームワークだの手当たりしだい読んでます。まだまだです…。