blog@longkey1.net

「第5回CakePHP勉強会@Tokyo 東海サテライト」に行ってきました。
個人的に非常に久しぶりの勉強会ということで、ドキドキしながら会場に向かいました。

第5回CakePHP勉強会@Tokyo自体がUstreamで配信されるということで、家でも見れたんだけど、名古屋でCakePHPのイベントは初めてだし、PHPerと絡みたいと思って行ってきました。

冒頭に少しだけ東京の会場から呼び掛けがあり、ちょっとテレビ中継みたいで楽しかった。
時代の進化はすごい、昔はテレビ局しかできなかったことが、今は素人が出来てしまうんだから。

サテライトというやり方は、最初どうなのかなって思ったんだけど、結構良かったんじゃないかというのが、僕の感想。
発表の合間合間に、前の発表に関する意見交換があったりして、一人で見ていると「あれってなんだろ？」ってのが、みんなの反応が見られるというのが新鮮でした。
もっと、ヤジみたいなのがあっても良かったのかなと。
どうせ聞こえないんだしさ。
行儀良すぎだったかな。

次回は同じ会場が使えない可能性が高いということで、開催が難しいかもしれないとのこと。
なんとか続けてもらえたらなと思います。

以下、第5回CakePHP勉強会@Tokyoの感想
■CakePHP1.3の概要(仮) 市川さん(@cakephper)
・結構知っていることも多かったかなという印象。
・CakePHP1.3のバリデーションにdatetimeを入れてくれても良かった気が・・・。
・プレゼン資料も文字が大きめで分かりやすかった。

■Ktai Library on CakePHP1.3(仮) 滝下さん(@ecworks_masap)
・来週名古屋に来ていただけるということで楽しみ！
・ざっくりとした内容の発表で、これまた大体知っている感じでした。
　けど、作者の方からの説明ってのは、やっぱり空気感が伝わって良いなとも思いました。

■コアライブラリのエレガントなハック 清水紘己さん(hiromi)
・正直難しかったし、良くわからなかった。
・すごく深い階層の話をしていて、ソースを追っていない部分に関しては全くわからなかったのが残念。
・発表者の方も言っていたけど、僕は今のところCakePHPのコアライブラリに関するハックというのは、懐疑的かな。多分、そこまでしないといけないような仕様の場合は、他のフレームワークを使うだろうし、既にあるシステムの場合でもな・・・。
・CakePHP2.0になると、そういった部分が考慮されてくるのかな？


■ツイート君というtwitterの外部アプリを作った際に、直面した様々な問題についての説明。
・顔は一切写らなかったのでわからなかったけど、イケメンそうだった。
・ツイート君の解析アルゴリズムはすげー気になったけど難しそう。
・CakePHPって簡単！と言われると、そうそうと思いつつも誰でも使いこなせる危機感も同時に募るのが・・・。

今回の一番の収穫は、名古屋にもCakePHPをひっそりと使っている人が、少しだけいた事を確認できたことかな。
懇親会もプログラミングの話から、仕事についての話まで幅広く話すことが出来て良かったなと。
今後は僕も何かしらサポート出来たらなと思いました。

もう大好きだったWeezerはいないとわかっていながら、ついつい新譜をチェックしてしまう時期は過ぎ、もうWeezerに全く興味が無くなって久しいこの頃。
初期のWeezerを期待させる今作が突然登場（＠ツタヤ）した。

視聴してみたら、確かにあの頃のWeezerの雰囲気を感じさせてくれたけど、そんだけだった。
実際に何度も聞きこんでみると、やっぱデモ音源ってことで作りこまれて無いからか、聞くに耐えない。
音質も悪いしなー。
いや、音質が良ければ良いかっていうとそうでも無いんだけど、雑っていうか適当っていうか、やっぱたかがデモ音源というか。
最後の方は「こんな品質で売るなー」とさえ思ったもんな。
商売なんだろうけど、切ないな。

昔のWeezerが好きだったってだけでは、期待しては駄目な作品。
マニア向けだわ。
Alone IIとかっていう続編も出てるようだけど、なんだかねえ。
いろいろ残念。

久しぶりに技術書を読んだ気がするな。
昨年のRubyに続いて、今年はPython。
節操が無いなと思いつつも、心が赴くままに勉強する方がいろいろと良いんじゃないかと思う。
何よりもモチベーションが赴くままに。

2ヶ月前ぐらいにTwitMailBoxというサービスをPythonで作ったんだけど、一応動いてはいるけど、「ちゃんとコードが書けていない」＆「なんだか良くわかっていないので気持ちが悪い」という気がして、Pythonを体型的に学ぶ為に本を読むことにした。

Amazonのレビューでは結構酷評もあったりしたんだけど、Pythonの入門書ってあまり無くて、いきなりオライリー本っていうレベルでも無いと思うので、事実上の定番本となっているこの本を読んでみた。

結論的には「読んで良かった」って思う。
ベストではないだろうけど、現状ではベターな本の一つじゃないかな。

こういう入門書の本って、書かれている内容の一貫したレベルの統一感って凄く大事だと思うんだけど、この本はそこがあまりスムーズに出来ていない。
いきなり「プログラムとは～」って話していたかと思えば、始めて見る関数なんかがポンポン出てくるのには、ちょっと困ったりもした。

けど、この本を読めばある程度全貌は掴めると思うし、多少は掴めたんじゃないかな。
最低限オンライン上にあるマニュアルは読める程度にはなるんじゃないかなと思う。

おぼろげだったPythonの印象もはっきりとしてきて、やっぱRubyよりもカッチリしている印象。
Python3になって、よりそれが顕著になっているんじゃないかな。
そして、Pythonなんか使っているとPHPのゆるゆる具合が不安になってくるのも確か。

んー、やっぱ多言語勉強するのは良いことだね。
懐が深くなる気がする。
これからはPythonの勉強会にも参加していきたいな。

※2010/5/17 追記 Ktai Library0.3.2にてこのバグは対応済みです

CakePHP1.3＆Ktai Library0.3で、Layoutを使うと文字コードが変換されないという現象を確認。
多分CakePHP1.2でも同じ現象かと。

ソースをみてみたところ、KtaiHelper::afterLayout()で文字コードを変換している模様。
ここで変換してしまうと、レイアウトを使用していない場合は処理通らない。

ということで、この辺のフック処理の順番を調べてみた。
最初はKtaiHelper::afterRender()に書き換えればいいかなと思ったんだけど、ここに書くと今度はレイアウトを利用している時に、レイアウトに適用されない。

なので方法論としては二つあると思う。
A) レイアウト利用時も利用していない時も通るところで変換する
B) それぞれの場所で変換処理を行い、既に変換処理を行った場合はしないように分岐する

A)の場合
実質、Controller::afterFilter()しかない。
が、ここでやってしまうと大雑把過ぎるというか、今まで出来ていた「このViewの時だけ変換しない」みたいなことを、気軽にViewファイルに書けなくなった。
これは面倒だなと。
ということで、B)のやり方でもやってみた。
CakePHPのソースを久しぶりにこんなに追ったなー。

@KtaiHelper

var $options = array(
	'img_emoji_url' => "/img/emoticons/", 
 
	'output_auto_encoding' => false, 
	'output_auto_convert_emoji' => false, 
	'output_convert_kana' => false, 
	'output_use_layout' => true, //追記
);

function afterRender(){
	parent::afterRender();

	// convert, encoding, shutdown
	if(!$this->options['output_use_layout']){
		$this->_shutdown();
	}
}

function afterLayout(){
	parent::afterLayout();

	// convert, encoding, shutdown
	if($this->options['output_use_layout']){
		$this->_shutdown();
	}
}

function _shutDown(){
	$out = ob_get_clean();
	$input_encoding  = $this->options['input_encoding'];
	$output_encoding = $this->options['output_encoding'];
	
	if($this->options['output_convert_kana'] != false){
		$out = mb_convert_kana(
			$out, 
			$this->options['output_convert_kana'], 
			$input_encoding
		);
	}
	
	if($this->options['output_auto_convert_emoji']){
		$this->convert_emoji($out);
	}else{
		if($this->options['output_auto_encoding'] && 
			($input_encoding != $output_encoding)){
			$out = mb_convert_encoding(
				$out, 
				$output_encoding, 
				$input_encoding
			);
		}
	}
	
	ob_start();
	echo $out;
	
	$this->_lib3gk->shutdown();
}

見てもらえたら直ぐ分かると思うんだけど、以下のことをやっている。

・$optionsのパラメータ（output_use_layout）を一つ追加
・追加した$options['output_use_layout']を見て、レイアウトを使っているかどうか分岐。使っているならtrue（デフォルト）、使ってないならfalse。
・分岐先の処理は、以前afterLayoutで使われていた変換処理をそのまま流用

どっかにlayoutを使っているかどうかわかる変数がないかなーと思って探してみたけど無さそうだったし、この辺仕様変更で影響を受けるのも勘弁して欲しいところだと思うので。

これで、Layoutを使ってないviewファイルに

$ktai->options['output_use_layout'] = false;

なんて書いちゃえばOK。
んー、お手軽。

とりあえず応急処理はこんな感じで。
作者の方もこの不具合は把握しているそうので、次のバージョンでは解決されると思われる。

期待してます！

今、出来るだけ買い物をクレジットカードで行うようにしている。
そういうふうにやり始めてもう3年ぐらい経つ気がするんだけど、生活もガラッと変わるのでもう一度再選定してみようと思っていろいろネットで調べてみたので、それのメモ。

まず、そもそもなんでクレジットカードを使うようにしているのか？ってことなんだけど、理由は以下の通り。
1) 家計簿代わりになる
2) ポイントがたまってお得
3) 海外旅行に行く時の保険代わり
の3点。

めんどくさがり屋の僕にとって家計簿とかは無理難題だったので、クレジットカードを使えば勝手に記録してくれるじゃん＝楽という図式。
まあ、あと現金で買ってもカードで払っても値段が同じならポイント溜まった方がお得だよねってだけの話。
3番目はあんまり実感して無いんだけど、まあいくらか保険が付くということらしいので。

■現在利用しているクレジットカード
・オリコ　UPty（アプティ）（メインカード）
・ライフカード（サブカード）

■検討した結果
・オリコ　UPty（アプティ）（メインカード）
・ライフカード（サブカード）

結局変わらなかった。

オリコ アプティは使い始めた頃と比較すると大分ポイント制度が改悪されてた。
まさか公共料金の支払いはポイント2倍ってのが無くなっているとは・・・。
ポイントだけなら、ポーラスターカード プラスが一番だと思う。
オリコ アプティの還元率は最大1.25%、一方ポーラスターカード プラスは1.66%だとか。

だけどオリコ アプティをそのまま続けようと思った理由は
・支払い先を別のカードに変更する手続きが面倒
・ポーラスターカード プラスは年会費（\3,150）かかる為、思ったほど還元率に開きはない
・一部ポイントが付かない商品がある
など。

要はメリットの割にメンドクサイってこと。
これがもう少しお得なら考えるんだけどねえ。

まあ、ライフカードは「オリコ アプティが使えない時」と「ポイントが5倍になる誕生日月」しか使わないって使い方なのでそのままかな。

んーいろいろお得に過ごすってのは難しいなあ。
こんなことをごにょごにょ考えている自分は、やっぱ小物だなあと改めて思ったわ。

・・・う。