アップデートしたら何か動かなくなりそうで怖くて出来ないと思った浅はかは愚かしい。
今度はWordPressのテーマ実装はどうなってるのか調べてみました。
% tree wp-content/themes/default
wp-content/themes/default
|-- images
| |-- audio.jpg
| `-- kubrickheader.jpg
|-- index.php
`-- style.cssほう、テーマディレクトリ自体がDocumentRoot以下にあると・・・。
あ…ありのまま 今 起こった事を話すぜ！
「おれはテーマを晒さない方法を調べていたと思ったら、 いつのまにか問題にすらなってなかった」
AA略
なるほど・・・これは、頭に無かったな・・・いや、しかし・・・。
ブログツールのテーマ実装の参考にRadiantを調べてみた。
テーマ以外の部分でもrailsのOSSアプリを作るために参考になる仕掛けが一杯あって参考になりました。
しかし、全体的にソースがとても綺麗・・・。
「CMSの実装ってのはよぅ、こう、もっとドロドロした・・・おっさんの内臓みたいなものであるべきだろう？」
などとつぶやいてみたが駄目。
RadiantはそもそもCMSってこともあって、テンプレはDBにもってプログラムで出す形。
要はroutesの一番下に
map.with_options(:controller => 'site') do |site|
(...)
# Everything else
site.connect '*url', :action => 'show_page'
endみたいなこじゃれた事が書いてあって管理画面とか以外のurlは全てSiteControllerが捕まえるようです。そしてResponseCacheという自前のキャッシュのためのモデルを使ってる。（ARじゃなくてファイルに保存する）
キャッシュファイルは/style.css.(data|yml)/みたいになってて、dataがcssやhtmlの中身で、ymlにはLast-Modifiedみたいなヘッダのメタデータが入ってる。ETagやX-Sendfileもちゃんと処理してあって、なんだか真似して実装するのは大変そうだなぁ、といった感じ。
そもそもサンプルのテンプレ見ると”“画像とjavascriptは外部から読み込んでる”“んだよね。
キャッシュはrailsのpage cacheで済ませられないものかと考え中です・・・。
前回までのあらすじ：
今時自作のブログでやっていたが、Potageの方が全てにおいて良さそうなのでやる気がダウン。
軸がブレながらもやっていくしかない・・・。取りあえず見た目をかえられるテーマの機能を実装しようと思いました。
RailsのAPIをみると、ActionController::Base.prepend_view_path(path) なんていうのがある。（view_path＝viewのLOAD_PATHみたいなもん）
テーマ名（例えばplain）という名前を入れて、
cd $RAILS_ROOT
tree theme
theme
`-- plain
|-- images
|-- javascripts
|-- stylesheets
| `-- application.css
`-- views
|-- docs
| |-- _doc.html.erb
| |-- index.html.erb
| `-- show.html.erb
|-- layouts
| `-- application.html.erb
`-- settings
`-- edit.html.erbというようなディレクトリ構成にすれば終了か？と思ったら、imagesやstylesheets、javascriptsはpublic以下に無いから見えない。
パッと考えられるのは下記２点。
- テーマを指定したときにpublic下にコピーする。（typoがこの方法をとっていた）
- 静的ファイルを表示するactionを用意する。（無駄っぽくてやりたくない・・・）
どっちも嫌だなぁ・・・。
RadientCMSやRedmine、WordPressなどはどうやってるのか見てみようと思います。皆様はどうすればいいと思いますか？
option ＋ command ＋ esc でアプリケーションの強制終了できたのか〜。いちいちkillしてて面倒だと思ってたんだよ！
MOONGIFT: » とにかくシンプルなブログエンジンが良い方は「Potage」:オープンソースを毎日紹介
うわっ、こっちの方がいいじゃん・・・。
自戒の意味を込めて。
参照：いやな法則
生産性
- 前任者のコードは思っているほど汚くない。
- テストコードがたまった頃にもっと良いテストスイーツがでる。
- フレームワークのバージョンアップはうまく行かない。
勉強
- 習得に苦労した知識に固執する。
- 副業だけ評価される。
- 無駄な知識ほどのめりこむ。
- 軽視していた知識が評価される。
決断
- MSオフィス購入数はエンジニアが決めると失敗する。
本の整理に関して一番ネックだったのが、
「読んだ事のある本の管理」
です。（持ってない物も含むので蔵書じゃない）
せっかく読んだんだから記録しておきたいんだけど、レビュー登録とか面倒。兎に角大量にあるし。
そこで今回試してみてとても良かったのが、皆様のどのご家庭にも一つは必ずある、USBバーコードリーダーです。
 |
|
USBバーコードリーダーはUSBキーボードとして認識され（MacもOK）、光を当てて読み取ると、ISBNそのままの文字列＋改行コード（¥r¥n）をキーボードから入力したのと同じになります。
つまり、Excelか何かを開いてピッピ、ピッピと読み取って行くとISBNコードの一覧ファイルが出来上がります。（改行コード入るのでエンター押す手間も無し）
兎に角ピッピと読み取りながら本をダンボールに詰めていきます。
これはもはや本屋の棚卸しに匹敵するほどのこれ以上ないスピード効率であると言えるでしょう。
勘の良いプログラマー諸氏のこと、この行志向ファイルがヘテロジーニアスな蔵書管理界で最もシンプルで信頼出来るフォーマットであることにはお気付きでしょう。
これとGoodreadsなどの蔵書管理サービスAPIやISBN10-ISBN13相互変換ライブラリなどを組み合わせることで、このソリューションの安定性とスピードは全盛期のシューマッハを超えると言われています。
※下記がこのソリューションが解決する問題です。