雪

AM9:00頃ですか、一気に雪景色。

メモリ増設

メインマシン XPS M1330 のメモリを増設しました。
今更ながら WindowsVistaです。

Windows7機のアイソレーションタイプのキーボード、いまだに馴染めません＾＾；

さて増設です。
メモリも随分安価になったのですねぇ。
2GB×2枚で4000円弱。Amazonでお買い上げ。
そして開封の儀です。

アイ・オー・データの SDX667-2GX2/EC という商品です。

バッテリーを外して差し替えます。

で、起動します。

起動時にアラートが表示されます！

「メモリが交換されたのでなんたら・・・」（写真なし）

一瞬焦りましたがBIOS画面を確認してから起動。

無事起動しましたとも、ええ。

劇的な変化は見受けられませんが、スワップが減りました。ハードディスクが静かです。

さて、本機は 32bit OS なので 4GB すべては認識できません。

なので伝え聞いていたRAMディスクユーティリティなるものを導入しようと思います。

http://www.iodata.jp/promo/soft/ram/ramphantom.htm

RAMディスク作成　RamPhantomEX LE

こちらのサイトからシリアルNoを入力してソフトをダウンロードします。

が、シリアルが違う！というメッセージが・・・。なんという・・・

調べてみると当該ソフトウェアの適合商品ではないことが判明！あらら

結局こちらは断念しました。残念。

RAMディスクユーティリティ導入を前提にメモリご購入をお考えの方はどうぞご注意くださいませ。

実際の開発環境はどうなのか？といいますと相変わらずディスクスワップします。快適とまではいかないもののストレスは減りました。

「コスパ」は「グー」ですよ。

Webアプリなときの基本構成はこんな感じです。

NetBeans7

VMWarePlayer でCentOS

Chrome

Firefox

その他

今までよくがんばってたなぁ。これからも頼むよ！

雪ですよ

先ほど、吹雪いておりました。
今は日差しがあります。
路面はドライ。

広島市佐伯区五月が丘から

setFlash()されたかどうだか

いろいろとメッセージを表示したいものです。
そんなとき setFlash() って便利！
$this->Session->flash() する前に中身を確認したいときってあると思います。

$this->Session->setFlash('ホニャララ');
$hoge = $this->Session->read('Message.flash');

とすると、

$hoge['message'];

で確認できます。
他にもパラメータを渡せるようです。

http://book.cakephp.org/2.0/en/core-libraries/components/sessions.html
SessionComponent::setFlash(string $message, string $element = 'default', array $params = array(), string $key = 'flash')¶

PHP連想配列の先頭にアイテムを追加

連想配列の先頭にアイテムを追加したい。

$ary = array('001' => 'item1', '002' => 'item2', '003' => 'item3');

array_reverse($ary);
$ary['addkey'] = 'addvalue';
array_reverse($ary);

ひっくり返した配列にアイテムを追加してまたひっくり返す。

セレクトボックスのソース使用している連想配列の先頭にアイテムを追加したいときなど。

CakePHP2で一覧形式のデータを保存する

こんな感じです。

foreach($data as $rec) {
  $this->Model->create();
  $this->Model->id = $rec['id'];
  $this->Model->save($rec, false);
}

ループの数だけSQLを発行するのですね。
フレームワークの魔法はなかったのです。

create()を忘れずに！

cakePHP2 「設定より規約」

CakePHP2です。

「設定より規約」

"convention over configuration"

なるほど、わかります。
これにピッタリハマる案件は幸せです。保守も楽チン？？？

さて、既存システムのリプレース、やり方はいろいろとあると思います。

予算などなどいろいろな制約の都合上、既存システムからの移行でDBはそのままでいくぜ。
ということもあると思います。結構あると思います。

こんなとき、この「規約」がフレームワークを使用する上でのメリットと、まさにトレードオフになったりならなかったり。

親子関係を持つレコードセットを取得するとき、規約に則っていれば、

find('threaded',…)

などで簡単に取得できます。（これスゴイ！）
がしかし、既存DBレイアウトのままのときはそうもいきません。

join して、find('all', …)　で取得したレコードセットを親子関係になるように整形する必要があります。
　ここのコストが結構なものだったりします。
どうせビューでforeachするからそこでやっちゃえよ。というのもわかります。
でもモデルで親子関係の配列を返してやればメンテナンスも楽チンなのです。

実装するとき、SQLがスッと頭に浮かぶのだけれども、せっかくのフレームワーク、ここは「規約」にのっとって、fields/conditions/join/order などを find()メソッドに渡すように書こうとすると結構時間がかかります。（慣れですかね。）

求めるSQL文は頭にあって、それを生成するような、「規約」にのっとった書き方をするのは、ううむ、と思うこともあります。
生成されるのは、結局SQL文です。なので素のSQLをイメージできなきゃ、「規約」も絵に書いた餅ということですね。