2012-02-08
CakePHP2のTwitterBootstrapプラグインがかっこいい
CSSフレームワークのような、Webアプリのフロント用ツールキットのような、TwitterのBootstrapがいい感じです。フォームのmargin/paddingの具合やプリセットの表現がほんとスマートで、やりすぎないのにすごく丁寧。
http://twitter.github.com/bootstrap/
そのBootstrapのかっこいいフォームのスタイリングなんかをCakePHPでさくっと使えるようにしたプラグインがこちらにあります。
https://github.com/slywalker/TwitterBootstrap
- このGitHubプロジェクトをまるごとCake2の app/Plugin/TwitterBootstrap に入れる。
- app/Plugin/TwitterBootstrap/webroot に bootstrap の js, css, img をぶちまけ。
- プラグインの中にある View/Layout/bootstrap.ctp と View/Element/alert.ctp を app/View の下の各所にコピーしてくる。
これであとは、app/Console/cake bake するとき増える適当なbakeテンプレートを選べばOK。コントローラとビューにそれぞれ、プラグインからbakeテンプレートが提供されます。
以下、ほんとに bake しただけのビューの周りをちょっとだけカスタマイズしただけのものです。
やったのはパンくずウィジェットを入れたぐらいで、アプリケーションロジックっぽいことはいっさいやってませんが、なんだか頑張った感があってかっこいいですね。もっとがんばったら、というか、あまりがんばらなくても、Bootstrapのプリセットのスタイルやアイコンを引っ張り出して来るだけで、もっとオシャレな感じにもなると思います。
エラーまで勝手にかっこよくなりました。
余談: あとで app/Config/bootstrap.php を開いてHTMLをデザインしようとしてああってなりました。ファイル名が似てるけど間違えないように注意しましょうオレ。
2012-01-20
Gitで空フォルダを管理したいときemptyを使うか.gitignoreを使うか
で、2つの流派に分かれるempty派と.gitignore派ですが、うまく使い分けるといい感じになります。
.gitignore はキャッシュやログなど、システムがその中にファイルを作るフォルダに、 empty はもしかしたらその中にソースコードを入れるかもしれないけど今のところ空っぽな場合、 と、それぞれ使い分けると好都合。
* !.gitignore
と書いた .gitignore を作ると、その中に入っているファイルは全部無視されて、ソースコードを入れて git commit -a してもユーザへのフィードバックなしにスルーされてしまいます。また、作業者に対して、パッと見でそこが無視フォルダだからファイルを置くとき注意しないといけないと気づかれない可能性もあります。その代わり単体で意味を成すので、より上位の.gitignoreと関係しなくて済むのでシンプルです。
empty が置かれているフォルダでファイルが作られてしまうのを無視するには、より上位の.gitignoreで別途指定しないといけません。その方法を多用していると、(GUIを使っている場合はとくに)うっかりemptyファイル自体が無視されているのに気付かないことがありますし、それを登録するには、git add -f folder/empty というコマンドを打たないといけなくて作業のスムーズさがなくなります。
emptyを置いたままだというのを忘れていても、ファイルが commit -a に含まれるほうが良いですね。まあ、中身のない .gitignore を置いても同じなんですが、隠しファイルでないほうが消し忘れに気付きやすいのであえて empty にしておくのがいいと思います。そうすると、.gitignore はそれ以外全部無視で、empty は作りかけだから空っぽという意図の表現にもなりますね。
もともとここ http://tipshare.info/view/4f1917394b2122f523000000 に書いてたんですが、やたら長文になってしまったので、別途読みやすいフォーマットのとこに転記しました。
2012-01-17
PHPでHTTPレスポンスコードを返すときPHP_SAPI分岐は要るのか
こたえは「たぶん要らないんじゃないの」です。はいおわり、というのでは何の話かわからないので、以下に詳しく書いておきます。
PHPのマニュアルで header() 関数を調べるとこんなことが書いてありました。
特殊な header コールが 2 種類あります。最初のものは、 文字列 "HTTP/" から始まる全てのヘッダ (大文字・小文字は区別されません) です。 このヘッダは、送信する HTTP ステータスコードを示すために使用されます。 例えば、存在しないファイルへのリクエストを処理するためにある PHP スクリプトを使用するよう (ErrorDocument ディレクティブにより) Apache を設定する場合、 そのスクリプトが正しいステータスコードを返すようにする必要があります。
< ?php header("HTTP/1.0 404 Not Found");FastCGI の場合は、404 のレスポンスは次の形式でなければなりません。
< ?php header("Status: 404 Not Found");
http://www.php.net/manual/ja/function.header.php
Statusの方式で返すのは、FastCGIというよりCGI一般の仕様なので、旧来からのCGIにも通じる話です。で、これに従うと、ステータスコードを返す正しい処理というのは以下のようなかたちが正しいということになります。
if(preg_match('/^cgi/', PHP_SAPI)) {
// Status: のほうを使う
}
else {
// HTTP/ のほうを使う
}
ところが、これ指定しなくてもなんか動いてるみたいでした。で、気になって調べると、CakePHP2とSymfony2のソースにはこの分岐がありませんでした。逆に、Smartyには php_sapi_name() で分岐が書かれていました。テンプレートエンジンになんでそんなものが、というのは、304 Not Modified 対応っぽいです。そんなものはコントローラでやるわいというのはさておき...
nginxとFPMで実績がありそうなほうがCGIを意識してないのはおかしいぞというわけで、じっさいにCGIでPHPを叩くとどうなるか調べました。これがPHPの(Fast)CGIにおける真実です。
はい、結論。CGIモードのPHPは HTTP/ で指定したヘッダがあったらそれをStatusに置き換えてCGIの応答に使い、それを受けたApacheやnginxが勝手にレスポンスコードの記述に変換してくれる。プロトコルバージョンで1.0を指定しているのに1.1になってしまうのがその証拠。
まあ、試した環境が新しすぎてそういう機能があるのかなとも思うので、PHPの5.0代とか持ってる人がいたら試してもらえると嬉しいです。
そうそう、ApacheでCGIにPHPを使いたいときは、php.iniの cgi.force_redirect = 0 を忘れるとハマるのでご注意ください。
2012-01-05
Yiiフレームワークでもっと理解したいMVCの話
2011年内に書ききれなかったトラックバックです。あけましておめでとうございました。
PHPのアドベントカレンダーに Ruby on Rails と CakePHP と Django と Symfony2(*1.x とは別物なので2と明記) の特長がうまくまとまってるいいエントリが書かれていました。
フレームワークで語るMVCの話 : PHP Advent Calendar #19 - basuke の日記
で、Yii をネタに加えて、勝手に追っかけたいと思います。Yii を題材にしますが、だからみんな Yii を使えという話ではなく、MVCフルスタックフレームワークは Yii から学ぶことがいっぱいあるという話です。
2011-10-20
Pano: タブをサイドバー化するFirefox拡張の決定版
最近普段使いはChromeなんですが、やっぱりFirefoxは開発や調べ物に最適で、ずっと使っています。Firebugとそのエクステンションはまだまだ最高ですよ。けどそういう目的に使っていると、すぐにタブがいっぱいになってしまい、どれがどれだかわからなくなってしまうんですよね。
タブの幅が狭くなるとタイトルが十分に表示されなかったり、増えすぎるとスクロールアウトしたり...
サイドバーにタブを縦に積んで、確実に幅を確保しつつ、しかも縦だからそうそうスクロールアウトもしないというのが欲しかった。IEで十分だった頃はSleipnirがあったのにな、と。
というわけで、これまではこんなのを使っていました。
ツリー型タブ (Tree Style Tab) :: Add-ons for Firefox
が、これがまた多機能すぎてちょっとたいへんで、もとからあるサイドバー機能は利用せず、要る物ぜんぶ自作だった。Firefox4以降、本体は速く起動するようになっているのに、拡張機能のせいで遅くなるのは避けたかった。それで、4から増えたタブグループ機能、いわゆるPanorama(Firefox内マルチデスクトップみたいなアレ)を使ってグループで切り替えほうがいいんじゃないかなと思い始めていました。そんな時、とあるMozillaの中の人のツイートでPanoに出会いました。
Pnanoの見た目。サイトにはMacのスクリーンショットがなかったので。
Panoは独自のタブ分類機能を持っていなくて、単に、Firefoxがもともと持っているタブグループ機能の別ビューにすぎません。サイドバーやポップアップパネルに、ビルトインのタブグループを縦に表示するだけ。すごく軽量でした。しかもPanoramaでできることのほとんどができます。もちろん即インストール。
ソースはGitHubにあって、ビルドがこれまたすごく簡単です。開発者にとっては嬉しいソース置き場ですね。
当時の安定版だと機能的に我慢できなかったので、クローンしてまだリリースされていない機能を使ったり、作者の @teramako さんとコンタクト取らせてもらって、いろいろ機能にワガママ言ったりしました。聞いて下さってありがとうございます。
そんなこんなで、安定版バージョン0.9がリリースされました。設定画面ができて、about:config をいじらなくてよくなりました。これは使いやすい。
実質のリリースノートはたぶんここです。
Pano 0.9pre の現状 - hogehoge @teramako
このあと0.9のリリース版には、GitHubで僕が送った小さなプルリクエストがひとつ入っています。
タブをたくさん開いてブラウジングする人はぜひ、Panoを使ってみてください。





