インストール
% gem install sqlite3-ruby rails --pre
% rails new foo
% cd foo
% rails generate scaffold Club name:string exclusive:boolean
% rake db:migrate
% rails server何でCMS作りたいかというと、WordPressが凄い便利だなーと思うからです。
デザイナー（@machidaさん）とプログラマー（俺）で会社をやってますが、デザインがメインの会社なので当然デザインの案件が多いです。そうすると、WordPressがあればプログラマーは何もしなくていいという案件がとても多いんです。
@machidaさんがWordPressを使い込んでるということもあるんですが、プログラマー無しでまともなWebサイトが作れるとかWordPress凄いなー。嫌だなー 怖いなー 怖いなー って思ってたんです。（褒め言葉）
でもまあ、時々はそのサイト向けに特化した機能や動きが必要になって、既存のプラグインでは対応出来ない時、プログラマー（俺）がプラグインをPHPで書くんですが、これが辛い・・・。
また、既存のプラグインで対応できるかの調査でそのプラグインのコードを全部読んだりするんですが、これもシンドイ・・・。（プラグインの作者がヘボイとかそういうわけでは全然無く、PHPとWordPressのルールと流儀をしっかり守ると逆にシンドイコードになるのです・・・）
それは我慢しろって話ですが、PaaS環境（GAE, Heroku）で動かないのがかなりダルイ。
WordPress用にさくらインターネットの500円の共有レンタルサーバーを借りるのがお決まりのコースなんですが、WordPress以外は全部Herokuに置くようになってから、@machidaさんが、
「何でWordPress、Herokuで動かないんですかねえ」
と、キレそうになっているのでHerokuで動くWordPress的な物が欲しいのでCMSを作ります。
.gvimrc
if has('gui_macvim')
set imdisable " IMを無効化
set antialias
set nobackup
set guifont=Monaco:h14
colorscheme darkblue
" ヤンクをクリップボードへ送り込む
set clipboard+=unnamed
" ルーラーを表示
set ruler
set title
" メニューバー無し
set guioptions-=T
" フルスクリーン時画面いっぱい
set fuoptions=maxvert,maxhorz
endifインストール
% bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head ).zshrcに追加
if [[ -s /Users/komagata/.rvm/scripts/rvm ]] ; then source /Users/komagata/.rvm/scripts/rvm ; firuby1.9.2をインストール
% rvm install 1.9.2ruby1.8.7をインストール
% rvm install 1.8.7デフォルトのrubyを設定する
% rvm --default 1.8.7-p299ブックマークしてもらった時に、「この人はブログやってるのかな？」と思う事が多くて、b.hatena.ne.jpのbをdに変えるお仕事が何か苦痛だった。
と思ったら、アイコン部分をマウスオーバーするとメニューが出てきて、その人がはてなで他に使ってるサービスが出てきた。便利ー。
最小プランは無料であるHerokuに静的ファイルを置くための雛形を作っときました。
$ git clone git://github.com/komagata/heroku-static.git
$ cd heroku-static
$ heroku create foo-bar-buz
$ git push heroku masterkomagata's heroku-static at master - GitHub
html, js, css, imageなど、静的ファイルだったらpublicディレクトリに置いてpushすればすぐ公開。
あんまり無料ホームページとして使われてもHerokuは困るだろうけど、git必須な時点で誰も彼も使うということにはならんでしょう（多分）。僕はjsとかのデモやサンプルを置く場所として使ってます。
中見てもらえばわかりますが、こういうのを置いてるだけです。
% cat config.ru
require 'rubygems'
require 'sinatra'
get('/') { open('public/index.html').read }
run Sinatra::Application必要な物がherokuのgemとgitだけなので慣れればGAEより楽だと思います。みんなで金払ってHerokuがパワフルになるといいな。
このブログのBundler化とRails2.3.5から2.3.8へのバージョンアップをやりました。
ハマったとこ
今までは
% haml --rails .とやって、vendor/plugin/haml/init.rbを生成していたんですが、それが要らなくなった。
init.rbの中はhamlを読み込む処理だったのでbundlerではbundlerが必要なライブラリを読み込むから要らないんですね。Rails3から必要無いというわけではなく、Bundlerを使った場合に必要無いってことなんですな。
認証
BASIC認証大好き（REST厨乙）なのでこのブログもBASIC認証なんですが、ついでにパスワードとかもHerokuの環境変数にしてみました。username: <%= ENV['CLOISTER_USERNAME'] || 'username' %>
password: <%= ENV['CLOISTER_PASSWORD'] || 'test' %>少し長めのJavascriptを書く時にtypoとかケアレスミスが目立ってきたので文法チェックしてくれるjslintをvimから使うjslint.vimを使ってみました。
（JavascriptでVNCクライアントを実装したJoelさんのインタビューでJSLintを使ってるというのを読んで気になってました。）
hallettj's jslint.vim at master - GitHub
READMEに書いてある通りで行けます。（Macの場合はこう）
% sudo port install spidermonkey
% git clone git://github.com/hallettj/jslint.vim.git
% cd jslint.vim
% rake installMacBookの場合、F5とかってfnキー必要だし面倒なので他に割り振った方が良さそうです。
quickfixで全部出してくれるので:cnで次々直していけるので便利！
面白いのが.jslintrcで、jslint.comで使えるオプションが指定出来るとこです。（チェックすると下の方の四角の中に出るヤツ）
そして何より素敵なのが僕も日本語版読んで大変勉強になったJavaScript: The Good Partsのルールを守れるように出来る事。（==じゃなくて===使えとか、++使うなとか、コンストラクタの先頭は大文字にしろとか。そもそもnewを使うなって書いてあった気がするけど…）
参照：
sudo port upgrade outdatedの途中で終了しちゃって中途半端な状態で終わってたからか、atlasがインストール失敗する状態になってた。
% sudo port clean -f --all atlasこうしたら治った。
最近仕事でWordPressのテーマやプラグインのコードに触れています。
WordPressには「結果を標準出力に出力する」か「返り値（文字列）として返す」かというフラグを引数に持つ関数がとても多い。
下記のコードは同じ動きをする。（実際にthe_titleの上記フラグは第三引数ですが分かりやすくするために簡略化しています。）
// エントリのタイトルを出力する
<?php the_title(); ?>
komagata [p0t]
<?php echo the_title(false); ?>
komagata [p0t]本体にこういう関数が多いため、プラグインでも暗黙的にその動作を求められる。
何で後者がデフォルトじゃないのか。そもそも、
// エントリのタイトルを出力する
<?= the_title() ?>
komagata [p0t]
こうじゃ駄目なのか？
これはショートタグがマナー違反とされているため、<?php echoと書くのが面倒でこうなっているんではないでしょうか。
そもそも何故ショートタグが色々なコーディング規約で非推奨になっているのかも理解出来ない。XML宣言と同じ事はそれ程問題なんだろうか。何かセキュリティーホールがあるのかな？
テーマの中で<?php echo とわざわざ書かなければいけないせいで、テンプレートがウリのPHPの良さが損なわれている気がしてならない。
WordPressではthe_xxx()という名前だからといって必ず上記の機能を持っているわけではない。そもそも返り値を返さない関数も多い。
リファレンスを見ると、最近のバージョンになるにつれてthe_xxx()は関数内で出力、get_the_xxx()は文字列として返り値を返すというルールが出来つつあるっぽいが統一されそうな気配は無い。
この手の瑕があちこちに見られます。大勢に使われることで成長してきたソフトウェアだから仕方のない事だと思います。しかし、もう大きく舵を切らないとマズいところに来ていると感じました。
特に安価なレンタルサーバーで動くことが大きな長所であるWordPressは無料からあるクラウド環境に対応出来ないと今後生きていけないと思う。
それにはデータベースの抽象化がほぼ必須だ。このまま生SQL CREATE文を抱えた大量のプラグインと一緒に沈没していく危険性が高い。
僕の考えたWordPress生き残り戦略
- 今のAPIは期限付きDeprecatedで残しつつ、クリーンでデータベース非依存のAPIを作る。（本家がやらなくても、プラグイン制作者用ライブラリを作るでも良い）
- PHP4の排除運動に便乗して一緒に旧API依存プラグイン／テーマを推奨しない運動を広める。（新APIへ対応するプラグイン／テーマ開発者・ユーザーをAutomattic社とか作者のMattとかが賞賛しまくる。）
- プラグイン・テーマのバージョンを見て、管理画面で嫌な警告を出す。
- １〜２年後ぐらいに旧APIを削除（ドーン！）
- ユーザーはいつの間にかクラウドに対応してる。
地味で当たり前で退屈な方法だけど今はじめないと手遅れになると思いました。