2009年1月アーカイブ

電源をいれたら、キーボードのバックライトが付くだけで、ディスプレイに何もうつらない。

サポートページを見て、PRAMだとかPMUだとかをリセットしてもダメなので、故障な気がします。

グラフィックチップか何かがリコールになってたりするんでしたっけ?

とりあえず、ジーニアスバーとやらに予約したので、明日診てもらってきます。

今は、前にDebian(Etch)をいれておいた Power Mac G4 を引っ張りだして来て使っています。

ただ、サーバとして使おうとしていたものなので、X やら日本語入力環境やら、時計設定やら、いろいろと設定が必要でした。

当初、Tiger を入れて代マシンにしようと思いましたが、ドライブの調子が悪く、インストールできませんでした。閉じても閉じても、開いてしまいます。

やっぱ、ネットブックというか、サブマシン的なものはあった方がいいのかもしれませんね。

bake して作った管理画面からの insert には成功する。
(ver: 1.2.0.7962)

test.php で、ENUM 型のフィールドを持つモデルのテストを実行しようとすると、テーブル置き換え(DROP & CREATE)に失敗する様です。

しばらくコードを追いかけてみたところ、それらしき部分が見えてきました。

テーブル作成で使う SQL を組み立てる中で、DboSource#buildColumn が実行されます。ここで、各データベース用のアダプタ(?)で定義される columns をベースにフィールドの型などを検証します。この時に、未定義である ENUM 型のフィールドは除外されてしまいます。

この事が原因で、テストのフィクスチャやコンソールのモデル焼きの中ででエラーが発生し、正常な処理の完遂が行われない、と判断しました。

スキーマ操作周辺で ENUM 型に対応できていないのは、取得した型情報が特殊だからでしょうか。ENUM 型の場合、「ENUM("X", "Y", "Z")」の様に括弧付きで、そのフィールド独自の値が埋め込まれているため、単純な実装では対処できない、としている様に思います。

さて、ENUM 型フィールドを含むテーブル作成ができないだろう事は、分かりました。が、実は、テストは問題なく実行できる事も分かりました。

冒頭で、「テーブル置き換え(DROP & CREATE)に失敗する」と書きましたが、これは実行するかどうかをテストケース内で指定する事ができます。今回の調査をするまで知りませんでしたが、クラスのプロパティとして"var $dropTables = false;"とする事で、テスト時にテーブル自体を作り直す処理が回避されます。

ただ、この回避方法は、環境によっては上手くいかないかもしれません。

CakePHP のテスト機構を詳しく見ていないので、正確な事は把握していませんが、「テスト用テーブルの準備やスキーマ変更のコストがかさむ」結果を招きそうな印象があります。

自分の場合は、テスト用データベースを利用し、テスト対象を実モデルとしてテーブル名を本番と同じものにしているため、本番用のスキーマをそのままテスト用データベースに流し込むだけで済みます。

一方で、記憶が正しければ、クックブック(book.cakephp.org)に従ったテスト環境の場合、テスト用のモデルとテスト用のテーブルが必要なはずです。そうすると、テスト用テーブルのスキーマも必要になるのでは無いでしょうか。

まあ、勘違いによる杞憂かもしれませんが。

結論としては、「ENUM 型も(それなりに)使える」という事だと思います。


公式情報を調べないままの結論なので、激しく間違えている可能性大です。技評の連載で普通に ENUM 型を使っているので、(ちゃんと CakePHP を理解していれば)普通に使えるんだと思います。が、ちゃんと理解していないので、やっぱり、それなりにしか使えないものだと思い込んでおきます。


おまけ:"MySQLのenumフィールドに対応" フォーラム - CakePHP Users in Japan

自分には対応できない状況に追い込まれたときに、バッチ処理で再インストールできたらいいな、と。

  • インストール済みパッケージの一覧
  • インストール済みパッケージのビルド済みなやつ

こんなものがあれば、さっくりと復旧できるのでしょうか。

何はともあれ、`port installed`すら実行できない様な状況に対応すべく、リストはバックアップしておくべきだと思っています。リストがなくなれば、長い事使わなかったパッケージをインストールする必要がなくなる、という利点(?)はあるけど、それは考えない事にします。

ruby で依存関係を考慮したリストを書き出すスクリプトを書いた方がいるようです。
きりかノート: MacPortsでインストールしたソフトウェアを依存関係を考えつつリストする

が、手元の環境で tcltk を require できず、インストールしようにもビルドでこけてめんどくさくなったので、MacPorts (のコマンド)の勉強がてら、シェルスクリプトでどうにかならないか遊んでみました。

variant やらバージョン番号やらが途中で消えてます。tsort もこれで正しいのか、あまり把握してなかったりします。

とまあ、とりあえず、出すだけ出してみました。

後は、パッケージ作りもインストールやアップデートと同時に行った方がいいのか、検討中です。そもそも、`port pkg`(でいいのかな?)とかを使った事がないので、まずそこからです。


リストのバックアップなどについて、ちゃんとした方法があるか調べてないので、それも調べないとですね。参照記事は、別件で目にしたものです。


バージョンとvariantも付ける様にしてみました。

MacPorts で大惨事

`port upgrade outdated`したら、しっちゃかめっちゃか。

何か(多分 gettext)のアップデートで、libintl の名称変更(アップデート)があり、libintl に依存したコマンド類が軒並み全滅しました。それだけなら、まだ救いはあった気がしますが、coreutils をインストールしていたので、大惨事です。

MacPorts を使った処理の中で、当然ながらいろいろなコマンドが実行されます。rm なり、chmod なり。/opt/local/bin を優先していたため、それらすべて、実行できなくなってしまいました。

で、処理が非常に中途半端な状態で終わり、「フェイルセーフ?なにそれ?おいしいの?」といった状況に追い込まれました。

パッケージを強制的にアップグレードなりインストールなりアクティベートなりしようとしても、「そんなパッケージはレジストリにないぜっ!」と反抗期を迎えます。

紆余曲折を経て、"/opt/local/var/macports/receipts/(パッケージ名)/(バージョン番号)"に本来削除されているはずのものが居座り続けている事が原因である事が分かりました。問題のバージョンのディレクトリを削除する事で、エラーメッセージも消え、無事にアップグレード作業を続ける事ができる様になりました。

インストール済みパッケージで、依存 dylib が見つからない事によるエラーが発生した場合は、その dylib に依存したパッケージを一通り強制アップグレードなりして、依存する dylib を参照し直す(?)様にしたら問題が解決するはずです。きっと。
libintl3.dylib に関するメッセージが表示され、port のビルド・アップグレード・実行ができない

後始末として、coreutils を削除して、OSX 組み込みのものを使う様にしました。元々、ls に色をつけたかっただけなので、`ls -G`と"CLICOLOR"および"LSCOLORS"で十分でした。その他のコマンドに関しては、違いを把握していないので、今後の状況次第です。

どうも、MacPorts は自分にとって鬼門な気がして仕方ありません。


"/opt/local/var/macports/receipts/(パッケージ名)/(バージョン番号)" に関して、公式ドキュメントなりを調べたわけではないので、万が一お試しになる方は、自己責任でよろしくお願いします。MacPorts のレジストリを扱う API があるとかないとか、という話がどこかにあった気がします…。それを使ってどうこうするのか、できるのかは知りません。

CakePHP で突然セッションデータが保存されなくなった。

  1. 作業再開
  2. セッションが使えなくなる
  3. ふて寝
  4. 作業再開
  5. CakePHP のコアを探索(session.php, set.php, ...)
  6. すったもんだ
  7. Session#__startSession で session_start できてない事に気づく
  8. ヘッダが送信済みでセッションを開始できていない事に気づく
  9. telnet で POST して HTTP の内容を見ても分からず
  10. AuthComponent とバッティングするとかあるのかとログイン処理を確認
  11. ヘッダ送信済みだとおこられる
  12. エラーメッセージの該当部分を確認
  13. !!!!
  14. PHP の開始タグが "2行目" だと言う事に気づく
  15. 空 行 始 ま り

ファイル先頭に空行があった事が原因でした。予期せぬ「ヘッダ送信済み」に遭遇したら、そこも疑わないと駄目でしたね。開始タグとか終了タグとか、さ。HTML をべた書きできるのは分かるけど、さ。HTML の中に PHP スクリプトを埋め込めるのは分かるけど、さ。はぁ。

正直、もう、自分は駄目だと思う。あと何日、技術者風に生きていけるだろうか。

あー、人生の岐路だ…。


だけの簡単なお仕事です - Google 検索

請け負った仕事の事を忘れて、現実逃避。

Rails でアプリケーション固有の設定情報を取り扱うための、一般的な方法がよくわからず、困っているところです。

おそらく、基本的には YAML ファイルを読み込み、シングルトンなオブジェクトを作成し、読み書きを行える様にする、といった方法がとられるのではと考えています。データ管理は YAML でなくデータベースで行うのかもしれませんね。

ざっと Google で検索してみたところ、日本語情報はあまり見当たりません。

英語情報は、そもそもどんな言葉で検索していいか分からないので、探していません。

大抵の場合、「設定より規約」で設定要らずなアプリケーションにできる、という事なんでしょうか。レアケースだから、一般化する事じゃない、という事でしょうか。

小さな設定管理用の仕組みを実装してもいいんですが、無駄な事をしている気持ちになるので、一般的な解決策を知りたいところです。

知りたいところですが、ちょっと調べても分からないので、検索して目についた Configatron (スペル難しいですね) について調べてみました。
KOSHIGOE学習帳 - [Ruby] Configatron

なんとなく、Configatron でいいんじゃなかろうか、という気になっています。


他にも、Rails 用プラグインとしていくつかあるという噂を耳にしていますが、Rails 専用ではないシンプルな(と感じた) Configatron を調べて満足しておきます。

ZendFramework を使って開発していた案件を、CakePHP で開発する様にしてみた。

個人的に請け負った案件で、ZendFramework を使っていたわけですが、(12月にサボりすぎて)時間がなくなってきたので、CakePHP を使った開発に切り替えてみました。出来合いのフレームワークで、Rails 的なやつなら、型にはめてしまえばさっくり行けるだろうという、甘い考えで見切り発車です。

で、早速困ってしまったわけです。クックブックを読みながら開発をスタートしたわけですが、これに従うと、モデルのテストをする際に、テスト用モデルを作る事になります。

テスト用モデルありきのテストをクックブックに従って書いた場合、フィクスチャでデータを入れる先もテスト用テーブル(_tests)になります(使うモデルをテスト用モデルにした場合)。こうして何が困るかというと、関連(hasOne や belongsTo など)を利用した機能のテストができなくなります。

実モデルで関連を定義した場合、当然実モデルの名前で関連付けを行います(よね?)。ところが、テストでは、テスト用モデルを使います。フィクスチャを再利用しようとして、全部テスト用モデル(を使うフィクスチャ)を使ってデータを入れてしまうと、実モデルで使うテーブルにはデータが入りません。そうなると、関連でデータを引っぱろうとしても、該当データが無いので、テストになりません。

というわけで(?)、そもそも「テスト用モデルをテストする」意味が分からなかったので、実モデルをテストする様にしました。(DB 切り替えのために継承してプロパティ書き換えるのは、どうなんだろうか。モデルは名前に意味を持つし、なんかすっきりしません。)

実モデルのベースになる AppModel 内で、テスト実行時にはデータベースをテスト用に切り替える様にすれば、実モデルを使ってテストをしても、本番環境を汚さずに済みます。DB が異なれば、テーブル名をテスト用に変更する必要も無いでしょう。
参考:CakePHP のテストは自動的にテスト用のデータベースを使うもんだと思ってた - pm11op のブログ

ひょっとしたら、設定項目を見逃していて、関連もテスト用に上手く切り替わるのかもしれませんが、実モデルをテストしたいので、テスト用モデルを使わずに済む方法でやっていこうと思います。

さて、なんだか暗雲立ちこめてきた今日この頃です。

2009 年は平成 21 年

今年こそ、年号での年数を忘れない様に 1 年を過ごそうと思う。

あと、いくつかの目標をたてて、2009 年を過ごそうと思います。

  • よく食べ
  • よく寝て
  • よく遊ぶ

非常に難しい目標ですが、なんとか、1年かけて、達成したいと思っております。

以上。

プロフィール

このアーカイブについて

このページには、2009年1月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2008年12月です。

次のアーカイブは2009年2月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。