T/O
rake pact:verify
の処理をどんどん中に降りていくと
ruby -S pact verify --pact-helper {helper}
のコマンドから rspec を起動する処理があるんだけど、ここで RSpec 2 だと –pact-helper という rspec が受け取れないオプションを渡してしまうという現象が起きる。
本来 Pact の RSpec への依存は 2.14+ になっているので直そうと思えば直せるのかもしれないが、たぶんそれをやるモチベーションを作り出すのはなかなか大変だろう。
自分も今回はそこまで修正量が多くなかろうという読みで RSpec のバージョンを上げる方法を選択して解決した。
ML を読み返していたら去年ウィジェットについてひとしきり盛り上がっていたのを思い出した。結局 Yahoo! Widgets がよさげだけど UI を作るのが激しく面倒くさいよね、というところで止まっていたんだけど、今見たら OSX でも Linux でも Google Desktop が動くようになってた。（Google 感度低いなぁ。）ということはガジェットも動くのかもしれない。
あ、でもこれって検索用のインデックス作成に時間掛かるとかインデックスが超でかいとかセキュリティポリシーとしてどうなのとか、なんかあちこちで見かけたやつかな？
うーん。あと、SDK は Windows 版だけっぽいな。とりあえずスルーかな。10.3 なので選択の余地ないんですけど。
CakePHP のおいしい食べ方: あのMamboがCakePHPを採用
ほーう。
あれだね、Zope の流行のあと軽い Web フレームワークが流行り、Rails が爆発して Rubricks が出現し、最近はやはりフレームワークに依存しちゃった方がいんじゃね的な感じが強いとは言え、ここまで大胆に行くのも珍しいかも。
ま、ちょうど「どうしても作り直したい」時期だったのかもしれないけどね。
ふと思ったけど、リンク先の言葉を借りると PHP は C の wrapper、Ruby は C のフレームワーク、と言えるかもしれない。PHP になくて Ruby にあるものの中で自分の中で最も重要なものの一つは「統一感」だから。
なんか夜中急に目が覚めたので（こういうパターン案外多いな）、何の気なしに昔の ML を読み返していた。
すると意外と当時分からなかったことが今なら分かるようになっている。それは技術的な内容だったり組織に関する概念だったり情報に関する概念だったり、本当にいろいろ、当時はなんとなくスルーしていたけど示唆に富む文章だったんだなぁと改めて驚く。
また自分が結構いろいろなことを考えていたことにも驚く。今は逆に頭の中のネタが技術的な方向に偏ってしまっているんだけど、これはもしかすると blog というかフィード中心に情報を漁っているからかもしれないなぁ。
幸い、前よりフィードの未読は貯まらなくなってきてるので、もっとアンテナを広げていかないといけないのかもしんない。
ちなみに ML を読み返し始めたきっかけは、入門言語としてCを薦めるか否かという話を以前読んだ気がしたからだった1のでついでに書いておく。自分はあえて C を入門として薦める気もない2けど、やっぱポインタと再帰は重要だったんだなぁと改めて思っているところ。なんつーかね、メモリをイメージできないのは結構致命的。てことで C も必要性を感じたらやればいんじゃね？という感じか。でも読めた方がなんとなくかっこいい気はするよね。そういう動機も悪くないと思う。メモリをイメージするためには C よりアセンブラとかの方がいいのか？
それより、問題をより小さい単位に分解して考え、個々に解決し、あとでそれを組み合わせて解決するというアプローチができるかできないかがものすごく重要で、そういうのってどうやったら身に付くのかなぁということをこの数ヶ月思い悩んでいる。というか自分はどうやってそういうアプローチが大事だと思うようになったのか、結構自然にそういう書き方ができるようになってきているのかが思い出せなくて、そこが歯がゆい。伝えられるものではないのだろうか。それなら諦めるしかないけど、どういうプロセスで体得した3のかさえも伝えることができないのだよな。もっとも、本当にあれもこれも糧になっているだろうから、だとするとやはりそんな簡単には伝えることはできないんだよな。
Google Calendar じゃなくて普通のクライアントアプリ + WebDAV でも結構使いものになるというか「面白い」1。
こういう善意の集まり的なシステムは利用者全員がちゃんと更新してくれないと意味がないという辺りで Wiki と同じ弱さを持つわけだけど、Wikiのように構造のないページというものにマークアップで構造を持ったテキストを書いていくという2、自由の代わりに引き受けた分かりにくさ、まどろっこしさはずいぶんと減るので、そこまで悲観的にならなくてもいいかもしんない。
特にマネジメント層の人は部下のスケジュールを複数組み合わせて全体の予定を見直す、なんてことが割と手軽にできそうなので逆に喜んで使うようになる可能性もある3。まぁどっちにしろ上の人のセンスというかスタイルに依存する部分は大きいわけだけれども、少なくともこれは直感的にメリットが分かりやすい。
純粋に個人で使うにしても予定の種類ごとにカレンダーを分けておくと、あとで WebDAV に放り込むとか HTML として出力するなんて操作をする際に楽なのはいいな。あとはこういうのが携帯から閲覧、編集できるとなおいいんだろな。
※ 排他制御とかどうなってるのなんて辺りはよく調べてない。少なくともすでに存在しているファイル名のカレンダーを新規に「公開」して上書きしてしまうことはできないようだ。
;; TAB コードはインデントに使わない
(setq-default indent-tabs-mode nil)
やっとすっきりした。
tabify, untabify
リージョンで
M-x (un)?tabify
参考
とりあえずメモだけ。
重いというより操作がまどろっこしくていやになった cocolog と /.-j の日記を掃除してしまわんとな。
- トップ階層（public_html/ 直下）には CGI を設置できない
- DirectoryIndex が CGI に対応してない
- これを .htaccess で対応させることはできない
- BASIC 認証用の passwd ファイルなんかも o+r にしておかないといけない
- 不可視にしたければ dot file にする
Perl とか PHP とかは動かしてないので知らない。しかし Ruby の shared library が load できないのは痛かった。
- xrea と違って Last-Modified ヘッダは問題なし
- でも tb-send.rb するためのライブラリがない
ライブラリをコピって tb-send.rb を有効にしてみたけど、shared library まで行き着いてしまった。手元の FreeBSD からコピってみた（やるか）けどダメだったので諦めておく。