portal shit!

やっぱりタスクをiPhoneから参照したい

いまでもThe Hit ListがMacでは一番好きなタスク管理ソフトだけど、iPhoneアプリがないのがさすがに不満になってきた。朝礼で予定を報告するときとかにタスクリストが見られないのが不便。iPhoneアプリがあればこういうことが可能になる。

The Hit ListのタスクはiCalのTo Doと同期できる。しかしiPhoneのカレンダーはiCalのTo Doの同期に対応してないし、そもそもiPhoneのカレンダーはできがあまりよくない。

2Do

iPhoneのタスク管理ソフトで2Doっていうのがある。これはUIがThe Hit Listに似ててなかなかよさげ。しかもMacのiCalと同期する機能がある（iCalのTo Doと同期できる）従ってiCalを介してThe Hit Listと2Doを同期できるわけだ。

しかしこのやり方には致命的な欠陥がある。The Hit ListはタスクをiCalのTo Doと同期するときに、入れ子になっているタスクの処理がへんてこりんになる。例えば、

タスクA -> タスクB -> タスクC

みたいな構造のタスクがあったとする。この階層構造を保持したまま同期されることを期待するけど、このアイテムがiCalのTo Doになったときは

タスクA:タスクC

みたいな表記になる。これは不便きわまりない。

というわけでせっかく買ったものの2Doには30分くらいで見切りを付けて（Lite版は無料だけどSync機能が使えない）、そして一年以上愛用してきたThe Hit Listも見限って、今後はTaskPaperを使ってみようかと思っている。

iPhone版のTaskPaperについては筆を改めます。

irbが素晴らしい！ 惚れた！！ PHPとかクソ！！！

まぁ、痴情のもつれが原因ですね。

ポータルシットに前も書いたけど、CakePHPの命名規約ではDBにusersというテーブルがあれば、モデルクラスにUser、コントローラークラスにUsersController、viewsディレクトリにusersっていうのが存在するのを前提とする。これに慣れてしまっているので、Railsのやり方にはなんか慣れない。ModelでPeople、コントローラーでUsersControllerとしてても問題ナッシングなわけだ。むしろRailsではこういうのが普通？ Rails使っててCakeをちょこっと触った人のブログにこういう感想があった。

コントロールとモデルが密すぎる。

CakePHPは、コントロール名とモデル名が密接すぎる関連を持っています。PostsControllerというコントロールを作ったら、必ずPostというモデルが存在しないと「モデルが見つからないエラー」になる。

Blog-side CakePHP わかりずらい３点

ふむふむ〜、ナルホディウスですぞ〜！！！

確かにCakePHPはモデルとコントローラーがガチガチになってて、あるコントローラーが他のモデルクラスにアクセスするときはいちいち

$use = array("Hoge");

とかしなきゃいけなかった。

最初の頃はモデル、コントローラー、ビューですべてが一対一に対応してるのですんなりMVCの流れを理解できたんだけど、今にしても思えばこういう考え方はすべてのコントローラーに対応するモデル（つまりDBテーブル）がなければならないというしがらみというか束縛を生じさせる。これでは自由な発想で開発できないし、下手をすると一つのコントローラークラスに大量にメソッドを書いてしまったりして、非常にメンテナンス性の良くないコードを量産してしまう公算がある。本当は機能ごとに細かくクラスは分けた方がいいはずだし、メソッドが一つしかないコントローラークラスがあっても良いはずだ。

そういうわけで、はやくこの辺のCake流の思い込みを排除して皆と同じようにrailsの手術を受けたいです。

なんじゃそれ！ 『Railsによるアジャイル〜』の15章 P239〜P240を読んでいてクリヴィッツテンギョウ！！！ app/controllers/admin/book_controller.rb ということができるらしい！ んで、そのときのクラス宣言は

class Admin::BookController < ActionController::Base

となるらしい！ 変態だ！！ ぜったい変態だ！！！

なんか Mephistoの公式サイト 死んでるし、jekyll に変えようかなと思ってるんだけど、 移行ガイド の通りにやってもうまくいかない。

CakePHPはなんも考えなくてもテキトーにやってたらサイトできてたんだけど、Railsはそんな風にはやらしてもらえない。Railsのサイト作んの自体の効率性が悪い訳ではもちろんないんだけど、レールに乗るためにはそれなりに知っとかなきゃいけないことが多い感じ。『Railsによるアジャイル〜』はいま14章まで読んだ。14章はテストの章だったんだけど、初めてテストに触れた感じ。CakePHP 1.2の公式ガイドにもテストについての章はあったけど、後ろの方でおまけみたいな感じだったから飛ばしちゃってた。たまたま先月の頭に買ってた『WEB + DB Press 56』がRubyでのテストを紹介してて、そこを読みながら14章のコードを写経していったけど、わりと早い段階でテストの重要性が説いてあって、アジャイル本はしっかりしてるわと思った。