php5.3から使える例外チェーンのメモ
<?php class FooException extends Exception { } class BarException extends Exception { } class BazException extends Exception { } function foo() { throw new FooException('foo error'); } function bar() { try { foo(); } catch (Exception $e) { throw new BarException('bar error', 0, $e); } } function baz() { try { bar(); } catch (Exception $e) { throw new BazException('baz error', 0, $e); } } // main try { baz(); } catch (Exception $e) { echo 'CATCH!', PHP_EOL; echo $e; }
$ php ./exception_test.php CATCH! exception 'FooException' with message 'foo error' in /Users/kalibora/src/php/exception_test.php:13 Stack trace: #0 /Users/kalibora/src/php/exception_test.php(18): foo() #1 /Users/kalibora/src/php/exception_test.php(26): bar() #2 /Users/kalibora/src/php/exception_test.php(33): baz() #3 {main} Next exception 'BarException' with message 'bar error' in /Users/kalibora/src/php/exception_test.php:20 Stack trace: #0 /Users/kalibora/src/php/exception_test.php(26): bar() #1 /Users/kalibora/src/php/exception_test.php(33): baz() #2 {main} Next exception 'BazException' with message 'baz error' in /Users/kalibora/src/php/exception_test.php:28 Stack trace: #0 /Users/kalibora/src/php/exception_test.php(33): baz() #1 {main}
例外をラップすべきかどうかは考える余地があるとして、
ラップしたい場合には便利。
ajaxの時ってビューロジックをサーバ側に置く?クライアント側?
ざざっとメモ。
例えば Employee というモデルがあり、 salaly プロパティを持っているとする。
DBに保存されてるのかどっかのAPIから取得するのかなどは問わない。
<?php // こんな感じで社員オブジェクトが取れるとする $employee = Employee::find($employee_id); // で給料はこれで取れるとする echo $employee->salaly, PHP_EOL // 200000
で、まぁテンプレ側で給料を表示する場合は、カンマ区切りで表示したいとする。
テンプレート変数に上記の $employee がアサインされてるとすると、
<html> <body> <?php echo number_format($employee->salaly) ?> </body> </html>
こんな感じかな。
それでじゃあこの仕様には意味が無いけど、この給料を非同期でajaxを用いて表示したいとする。
ajaxのAPIを作ってそれをテンプレートから呼ぶことになると思うけど、
そのajaxのAPIの返却値である給料にはカンマを入れるべきだろうか?
めんどくさいのでRESTかつjsonで返すと仮定すると、
GET http://example.com/employee?employee_id=1
こんな風に呼び出たら、
{ salaly: 200000 }
こう?それとも
{ salaly: 200,000 }
こう?
前者ならjs側でnumber_format相当のものを実装しないといけないし、
後者ならビューに特化しすぎてるので、そのテンプレートだけに特化したものになりそう。
また前者の場合でかつajaxでないページもあった場合、
そちらはサーバ(php)側で処理するから
ビューロジックはサーバ側にもクライアント側にも置かなくてはいけないので
同じ言語で書いているならいいが、
そうでないならビューロジックの定義が重複してしまう。
といったところで悩んでいたりする今日この頃。
Eテレ感想メモ
Eテレ見てたら面白かったので忘れないようにメモ。
- めざせ!会社の星「部下も必見!デキる課長の極意」
- 定期的にコミュニケーションの場を設ける。
- やっぱり話しかけづらいし、忙しい時は聞くのも大変なので。
- やるなら朝がいいらしい。これって朝会っぽい。
- 人に任せる。
- 細かく砕いて定期的にレビューする。
- 定期的にコミュニケーションの場を設ける。
- スタンフォード白熱教室 第1回「ブレーンストーミングで可能性を探せ」
- Yes, But じゃなくて Yes, And
- 座るより立ってやった方がいい
- これも上述の朝会と似てるなぁ。
fizzbuzzでもいろんな書き方がありますね。今の僕ならこう書く
なんとなくネットサーフィンしていたら上記の記事に出会い、
なるほど色んな書き方がある物だなと感じました。
でも個人的にはあまり好きではない書き方だったので
(応用2のFizzBuzzFozzの時にメソッドを呼び分けているのですが
このロジックは抽象化してメソッドにいれたほうが好みなので)
今の自分ならこう書くだろうというのを書いてみました。
※使い慣れないrubyなので慣用表現に誤りがあるかもしれませんが
そこはご了承ください。
#!/usr/bin/ruby puts '【基本】「まず基本的な FizzBuzz 問題を実現するプログラムを書きなさい' class Array def fizzbuzzify self.map do |i| case true when i % 15 === 0 then 'FizzBuzz' when i % 5 === 0 then 'Buzz' when i % 3 === 0 then 'Fizz' else i end end end end puts (1..100).to_a.fizzbuzzify puts '【応用1】「同じ処理を 100 まで、200 まで、1000 までの配列にそれぞれ適用しなさい」' puts (1..100).to_a.fizzbuzzify puts (1..200).to_a.fizzbuzzify puts (1..1000).to_a.fizzbuzzify puts '【応用2】「1000 までの場合だけ、30 の倍数の時に "FizzBuzzFozz" にしなさい」' class Array def fizzbuzzfozzify if self.count != 1000 then return self.fizzbuzzify end self.map do |i| case true when i % 30 === 0 then 'FizzBuzzFozz' when i % 15 === 0 then 'FizzBuzz' when i % 5 === 0 then 'Buzz' when i % 3 === 0 then 'Fizz' else i end end end end puts (1..100).to_a.fizzbuzzfozzify puts (1..200).to_a.fizzbuzzfozzify puts (1..1000).to_a.fizzbuzzfozzify puts '【応用3】「1000 までの場合だけ、標準出力でなく、hoge.txt に出力するようにしなさい」' class FizzbuzzFozzOutput def initialize(array_or_maxnum) case array_or_maxnum when Array then @array = array_or_maxnum when Integer then @array = (1..array_or_maxnum).to_a else @array = (1..(array_or_maxnum.to_i)).to_a end end def execute if @array.count === 1000 then File::open('hoge.txt', 'w') {|f| f.puts @array.fizzbuzzfozzify } else puts @array.fizzbuzzfozzify end end end FizzbuzzFozzOutput.new(100).execute FizzbuzzFozzOutput.new(200).execute FizzbuzzFozzOutput.new(1000).execute
まず、基本のFizzBuzzのロジックをオープンクラスで標準のArrayクラスのインスタンスメソッドとして追加します。
(標準のArrayに置くべきか、別のFizzBuzzArray的なクラスを作った方がいいかはちょっとよくわかりません。)
配列をFizzBuzz化する、という意味で Array#fizzbuzzify という名前を付けています。
なんとなく動詞っぽい気がしますが英語が得意でないので実際のところどうかはよく知りません。
応用1ではそれぞれの配列作ってfizzbuzzifyするだけです。
応用2では新たなロジックが出てくるので、それをまたArrayクラスのインスタンスメソッドとして追加します。
今度は Array#fizzbuzzfozzify としました。
1000までの場合という意味を厳密に考えるとめんどくさいので、とりあえず
1000個の要素の配列だった場合にFizzBuzzFozzが出るようにしています。
それ以外の場合は Array#fizzbuzzify に委譲します。
これで呼び出し側ではメソッドを呼び分ける必要はなく、どんな配列でも
Array#fizzbuzzfozzify を呼べばいいようになりました。
続いて応用3ですが、今度は出力先が変わります。
出力するメソッドをどこに置くかですが、Arrayに置くのもどうかと思ったので
新規で FizzbuzzFozzOutput クラスを作り、excecute メソッドで出力先が変わるロジックを吸収することにしました。
あと色気を出して、コンストラクタに配列だけじゃなく数値でも受け取れるようにしています。
いやらしいですね。
ソフトウェア工学的な読み物まとめ
個人的に何度でも読み返したい記事
- ソフトウェア工学とは何か ... 1992年の記事
- ¿·¤·¤¤¥½¥Õ¥È¥¦¥¨¥¢³«È¯¼êË¡ ... 2000年の記事
- - データベースの進化的設計 ... 2003年の記事
- Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている ... 2006年の記事
- 仙石浩明の日記: 「ソフトウェア開発」は「モノ作り」ではない ... 2006年の記事
調査したい
http://www.phpactiverecord.org/
と
http://framework.zend.com/manual/ja/zend.db.table.html
を使って
それっぽい業務モデルをActiveRecordパターンとTableDataGatewayパターンで実装してみて比較したい