レースクイーン情報

レースクイーンを各種ブログ(Blog)から一括検索します。

モバイル用に Server Side Google Analytics な感じで Google Analytics を(やろうと思えば)できる様なので、やってみようかとしているわけですが、全くもってできる気がしません。

考え方として、ビーコン(GIF Request)へのリクエストをサーバ側でやっとけば、統計情報を Google に送信できるわけで、そうすればいい、というのは分かります。そのパラメータ一覧も Google で公開されているので、必要に応じて渡したらいいだろう事も分かります。ただ、このパラメータ一覧の2つ目のutmccの意味が分かりません。

Google Analytics がブラウザに食わせた Cookie の内容を、ビーコンで送信するためのものだという事は分かります。分からないのは、その中身の値をどうやって決めるのかという事です。以下でそれらしき情報が公開されていたので、読めば分かるのかと思いましたが、具体的な値の仕様までは書いていない様な気がするわけです。
Cookies & Google Analytics - Google Analytics Tracking Code - Google Code

ブログ記事やGoogle Analyticsのフォーラムで、いくつかその辺の情報を見かけはしますが、それが何を根拠にしたものかよく分かりません。
Tracking from server side - Tracking Your Site | Google グループ
ある程度割り切ってしまえば(最低限何を記録できればいいのかはっきりさせれば)、十分な情報ですが、それなりに機能を追随させようとすると、心もとないわけです。ググって見つけた以下のコードでは、きっと割り切って、目的を絞った結果じゃないかと思ってみたりしています。

• モバイルサイトで Google Analytics
• gist: 14120 ? GitHub

で、とりあえず、ga.jsを読んでみればいいのかなと思い、Online beautifier for javascriptを使って整形してから読んでみたわけですが、さっぱりです。アルファベット1文字の変数が沢山あり、かつそのスコープがあれこれしててよく分かりません。ただでさえ、JSを理解しきれていないので、大混乱です。utmcc 関連の処理を追いかけて、Cookie に書き込むところまではおおよそで把握できましたが、肝心の値を決定している部分がまだ分かっていません。正直、やる気が起きません。疲れます。

で、コードを読んでいって思ったわけですが、結局、コード読んでまじめに Server Side Google Analytics の実装を目指してしまうと、不毛で無駄で無茶な作業になるのではないでしょうか。出来上がればそれはそれで価値があるとは思うんですが、とはいえ、Google が明確に仕様を公開していない(と思われる; 見つけられていません)ものを、コード(実装)を見てどうにかするというのも、なんだか今いちスッキリしません。

まあ、なんと言いますか、JSのコード自体読み慣れていないのに、あんな意味不明な変数名ばっかりのコードにつきあいきれない、というのが本音です。ソースコードの読み方を間違えて、無駄に苦労している様な気もしますけど。あと、(JSによるトラッキングから) Google Analytics でとれるレポートにできる限り対応した方がいいのかと考えてしまっているのも、問題を無駄に複雑にしているんでしょうね。

と、延々愚痴っていますが、気分転換(神頼み的)に出来上がりものがないかググっていた中で、以下にたどり着いたわけです！

13. 　財産権表示 UTM 及び Google Analytics ソフトウェア等を含む本サービス及び本サービスの全知的財産権は、全て Google （及びその 100 ％子会社）の財産であり、かつあり続けるものとします。 Google （及びその 100 ％子会社）が有するプロセシングソフトウェア及び付属文書の単独所有権等を含め、 Google Analytics ソフトウェアに関する権利であって本契約においてお客様に対して明示的に付与されていない権利は、全て無制限に Google 及びそのライセンサーがこれを明示的に留保・保有するものとします。前記規定の一般性を限定することなく、お客様は、以下の行為をせずかつ第三者にさせないことに同意します。 (a) 本サービスをサブライセンスし、配布し、又は本契約において付与された本ライセンスの範囲を超えて使用すること。 (b) プロセシングソフトウェアのコピー、改変、改作、変換、派生著作物の作成、リバースエンジニアリング、逆アセンブルを行い、又は逆コンパイルその他の方法で本サービスのソースコード若しくは本サービスに関連する営業秘密を探ろうとすること。 (c) 目的を問わず本サービスに関連する商標、商号、サービスマーク、ロゴ、ドメイン名及びその他の明確なブランド特性又は著作権若しくはその他の財産権を、 Google の書面による明示的な同意なしに使用すること。 (d)Google （又はその 100 ％子会社）に関連する商標、商号、サービスマーク、ロゴ、ドメイン名及びその他の明確なブランド特性又は著作権若しくはその他の財産権を Google （又は場合によってその 100 ％子会社）の名義以外で登録し、登録を試み、又は他人が登録するのを支援すること。又は (e) 本サービスに含まれるアイテムに表示されている著作権、商標又はその他の財産権表示を削除し、不明瞭にし、又は改変すること。
Google Analytics - Features

全く意識せずにソースコードを読んで、あわよくば移植とかも視野に入れていたわけですが…。躊躇せずオープンソースなノリで取りかかっていましたが、ga.js には(再利用可能を示す様な)ライセンスなんて無いわけです。(読める以上は)読むのは自由でしょうが、それ以上の事はサービス利用規約の制限内でやらないと駄目ですね。

正直、現時点で既に(b)の『リバースエンジニアリング、逆アセンブルを行い、又は逆コンパイルその他の方法で本サービスのソースコード若しくは本サービスに関連する営業秘密を探ろうとすること。』に抵触してしまった気がします。

営業秘密とは、秘密として管理されている生産方法、販売方法その他の事業活動に有利な技術上または営業上の情報であって、公然と知られていないもののこと（不正競争防止法2条4項）。

営業秘密を不当に使用した場合、一定の要件で不正競争行為となり、不正競争防止法違反となる。
営業秘密とは　〜　exBuzzwords用語解説

さて、どうしたものでしょうか。Google がオープンソースで、Pythonか何かのサーバサイドで動作するものをリリースしてくれませんかね？もちろん、JS だからこそとれている情報はとれなくなるでしょうけど、それはそれで。

モバイル端末用サイトでアクセス解析がしたければ、それに公的に対応しているサービスを使うべき、という事でしょうか。

作者:

更新日:2008年11月29日 0時58分

このブログのホーム

rake を yum でアップデートして、Passenger のワーカーをリスタートしたら、gem のバージョンコンフリクトで例外になった件。

あれこれ調べる前にたてた推測は、Spawner とかの常駐(?)している部分が抱えている rake が(メモリに)残ったまま、新しい rake が追加され、リスタートしたワーカー側で新しい rake を読み込もうとしたところ、gem のアクティベートに関する例外が発生した、というものです。

gem のアクティベートの例外メッセージは、ちょこちょこ見かけつつ、コードレベルで深追いしてこなかったので、適当に追いかけておきました。
KOSHIGOE学習帳 - [Ruby] Kernel.gem についてメモ

さて、気になっているのは、Passenger が Kernel.gem を使った gem の読み込みをしている様だということです。Apache のモジュールということでか、Ruby で書いたライブラリという事を忘れてしまっていたわけですが、Rails フレームワークを先読み(?)常駐(?)させる仕組みなわけだし、そもそも gem パッケージで配布されているわけだし、(Rails で使うリクエストハンドラとかの)Ruby コードを見た事があるわけだし、忘れてた自分が意味不明です。

まあ、なんと言いますか、「Web アプリケーションの部分で rake って使ってるんだ！？」という、個人的に盲点なところを突かれてまいったな、と。コンソールでの作業で rake が使われるのは分かるんですが、ウェブアプリケーション(Apache)の方に影響がある、というのがなんだかすっきりしません。

で、Passenger の gem パッケージの中を`ack "^[\s]*gem"`とかして探ってみると、テストコード以外では rails を Kernel.gem で読み込んでいる様です。

さて、gem のアクティベートについて調べた中で、依存関係にある gem もアクティベートする事を知りました。Rails をぼーっと使っているだけだったので、勝手にロードしてくれる事に慣れきって、Kernel.gem でやってくれる事の詳細に気が回っていなかったのは内緒です。

早速、以下のコードで、rails を Kernel.gem した場合に読み込まれるパッケージが何か調べてみました。

普通に、`gem dependency rails --version=2.1.2`とかして依存関係を調べるのと変わりませんね。

$ gem dependency rails --version=2.1.2
Gem rails-2.1.2
  rake (>= 0.8.1, runtime)
  activesupport (= 2.1.2, runtime)
  activerecord (= 2.1.2, runtime)
  actionpack (= 2.1.2, runtime)
  actionmailer (= 2.1.2, runtime)
  activeresource (= 2.1.2, runtime)

type が runtime なやつが、Kernel.gem での依存解決(ロード)の対象になるんですね。多分。そこは詳しく見てませんが。

後は、Passenger の Spawner だか Pool だかの所と、ワーカーの所でのあれこれを調べれば、rake のバージョンコンフリクトがどのようにして発生したかが分かるはずです。が、疲れたので、これ以上は気が向いたときに調べようと思います。その日が来るか知りませんが。

今回の収穫は、Kernel.gem した時の動きを多少知れた事ですかね。そんな事すら知らなかった自分に絶望するのはいつもの事なので、もう気にしません。スルー力ってやつですね。

作者:

更新日:2008年11月14日 23時19分

このブログのホーム

わけが分からないまま、FontForgeを使ってみたけど、どうにもならない。

(やっていいのかすら分からないまま)U+E63Eからの絵文字部分を既存のフォントにコピペしてみましたが、そもそもEmacsでのフォント設定がよく分かっていないので、特殊な文字に関してどうしたらいいのか全く分かりません。

OSXのCarbonEmacs.appで絵文字を普通に扱うためには、どうするのがベターなんだろうか？OSレベル(?)で外字だか特殊文字だかを編集(設定)できたりするんでしょうか。

絵文字を含んだフォントを生成して、そのフォントを正しくEmacsで設定することくらいしか思いつきません。本当にそれでできるのか、そうする方法はどんなか。さっぱりです。

作者:

更新日:2008年11月12日 21時57分

このブログのホーム

emacs-rails を調べる中で存在を知った、"Predictive Mode"。さっぱり、分からない。
KOSHIGOE学習帳 - [emacs] Predictive Mode

とりあえず、補完される事は確認したわけですが、いつ、どこで、どんな理由で補完されているのかが、よくわかりません。まあ、ドキュメントをちゃんと読めばいいわけですがね。どんなものなのかが知りたくて、ちょっと動きを見てみたかっただけなので、ほとんど読んでいません。チュートリアルっぽい所だけ、眺めただけです。

そんなわけで、未だ、emacs-rails のどこに関係しているのか、さっぱり分かっていません。predictive-prog-mode.elを見るる限り、Predictive Modeが有効になるのは、文字列とかコメントの中でしかないはずなので、上手く動かなくてもいいかなと思ってます。

そんなわけで、放り出しておしまい。

作者:

更新日:2008年10月5日 19時16分

このブログのホーム

営業の人がチケットをもらってきたようで。
新日本プロレスオフィシャルWEBサイト　-試合結果-

意外な程に夢中になれました。はじめは、生の蝶野が観れたら満足かと思ってたわけですが、あっとゆうまに夢中になりました。

「プロレスはプロレス」として受け入れられる様になっていたという事もありますが、なにより、リングサイドの、実況席のすぐ後ろ、永田の斜め後ろ、解説の人の後ろで観れたのが大きいんでしょうね。この席には驚きました。

いやぁ、やっぱり、小さめの会場で、生で観て、しかもリングサイドってのは、イイですね。

ひょっとしたら、プロレスの雑誌やらテレビやらに映ってるかもしれませんね。

んー、ひょっとしたら、後楽園ホールに通う事になるかもしれません。今度は、ボクシングを生で観てみたい。後楽園ホールくらいの大きさなら、席が後ろ(安そうな席)でも十分だろうし。

これを機会に、出不精が改善できればいいな、と。

作者:

更新日:2008年10月2日 23時1分

このブログのホーム

Rails を触りだしてはや半年。

正直、emacs-rails(rails.el)の機能は、バッファ切り替えくらいにしか使えてません。シェルでやれる事はシェルでやってしまってます。

簡単な機能リストが欲しかったので、この機会に浅くコードを眺めて機能を洗い出してみました。対象はSubversionリポジトリのrevision 232です。
KOSHIGOE学習帳 - [Ruby] emacs-rails

ちなみに、最近のemacs-railsではRSpecに対応していた事を知りました。とはいえ、バッファ切り替えには対応していない様なので、そこは自力で強引にねじ込んでいたりします。

これでちょっとは効率あがるだろうか。

作者:

更新日:2008年9月28日 0時45分

このブログのホーム

使うとスマートじゃない様子。
Ruby on Rails Code Quality Checklist - Articles - Matthew Moore

STI の仕組みを使わなくても、同じ様な事を実現するのは簡単で、STI に伴う弊害を考えると、STI は使うべきじゃない、といった事が書かれている気がします。ネックになっているのは、同一テーブルを使う事による密結合とかそういう話なんでしょうか。それ故に、マイグレーションが楽しくないとか、なんだとか？

原文である上記参考記事を見る前に、「STI 駄目なのか、実装が変なのか？」と勘違いしてコードを追いかけてたりしたわけですが、その存在自体が否定されているようですね？

まだ、駄目さが実感できていないので、何とも言えません。"Polymorphic associations"ってなんでしょう。STI によるアプローチは駄目だけど、ぽりもふぃっくな考え方はスマートだよね、というオチ(？)を付けたという事ですかね。

とりあえず、状況を見つつ、STI じゃないポリモフィックなアソシエーションの実現について、気にしてみようと思います。

おまけです。
KOSHIGOE学習帳 - [Ruby] Rails の STI について調査

作者:

更新日:2008年9月25日 2時8分

このブログのホーム

アプリ開発に踏み切る際の問題点(敷居の高さ)としてNDAがあるのを忘れてた。

開発において、技術交流を外せないと考えている方々にとって、NDAは敵でしょうね。

素直に、自身の成果物で利用者に利益をもたらし、自分にも利益をもたらす事で満足できれば、問題は全くないわけですが、交流的なところに主題(?)を置いてしまうと、NDAが大きな壁となって立ちはだかるわけです。きっと。

情報の共有は社内外において同一開発プロジェクトに関わる方同士のみ共有可能。
iPhoneをみんなで開発するにはどうすればいいか - ku-sukeのはてなダイアリー

クローズドなグループ内では交流できるようですが、気軽にブログに書き散らす事はできないわけです。まあ、社内外を問わず開発プロジェクトを立ち上げてしまえば、その参加者の間では交流できるわけで、クローズドソースとは言いつつも、仲間内ではオープンソースな関係は作れるわけですね。プロジェクト運営には、結構気を使わないと大問題になりそうですが。

とりあえず、Appleの努力(Safari安定化)に期待しつつ、"iPhone SDK Agreement"を読み進めようと思います。

ところで、SDKの同意書とは別に、"Registered iPhone Developer Terms and Conditions"というものがあるようですが、リンク先が404で困っています。気にせずに、ユーザ登録(した覚えが無い; Apple IDでログインできた気がするけど)をして、更にはSDKをダウンロードしてしまっているので、同意してしまっているわけですが、気になって仕方ありません。"iPhone Dev Center"のログインページにリンクがあるわけですが、404ってのはどういう事でしょうか。

ADCのユーザ登録は、以前に何かのディスクイメージをダウンロードするためにした記憶がありますが、iPhone用に登録した覚えがあるようでないようで、非常に曖昧です。まあ、今のところ問題になる様な事をした覚えが無いし、これからもする予定がないので、いいんですけど。線引きが理解できてないので、非常に不安です。まずいです。

そういえば、交流云々は、ADCのフォーラムとかがあったりするんですかね。相変わらず英語は鬼門としか思えず、積極的に関われないわけですが、Appleから場が提供されていれば、さほど問題(越えられない壁)でも無いのかもしれませんね？

作者:

更新日:2008年9月23日 15時55分

このブログのホーム

どうも、実家で 3G いけるらしい。

実家で、アンテナ5本たってました。昔の(3Gじゃないやつ)よりアンテナ事情よくなってますね。

おかげさまで、Byline を使って Google Reader の未読消化もできました。

さて、重大な事実に気がつきました。それは、Safari が安定しないのではなく、iPhone (のOS？アプリケーションフレームワーク？)が不安定らしい、という事です。

YouTube アプリをしばらく使い続けていたら、突然(YouTubeアプリ)落ちました。iTunes で音楽聞きながら、メモアプリで5行くらい書いたら(メモアプリが)落ちました(メモ内容は保存されてた)。

あと、アプリケーションを積みすぎたのか、動作(反応)がやけに重くなった気がします。メモリを消費しすぎているのでしょうか？

定期的に本体をリスタート(リセット？)させないと、駄目なんでしょうかね。

作者:

更新日:2008年9月22日 19時51分

このブログのホーム

単純にウェブアプリ(だけ)で何かしようとはできないね。

Safari は役立たずです。ちょっとした(利用時間が少ない)ビューワとしてはいいんですが、あれこれとアクションを重ねる場合には、本当に役立たずです。

iTunes と並行して動かしていると、特に顕著で、1ページ開いていて、スクロールしただけで落ちます。Safari だけ動かしているつもりでも、落ちます。

どこかで見かけましたが、原因はキャッシュやらのメモリ周りだとか、なんだとか？汎用にしたが故の難しさが、安定性欠如につながるんでしょうか？

とりあえず、モバイルだと、それほど多目的にする理由は無いと思うので、特化型アプリをたくさん積んでおくのが良さそうです。例えば、はてな touch とか、そんなんですね。

ウェブアプリだからといって、ウェブブラウザ(Safari)にこだわる必要はありません。使い勝手(ユースケース?)をよく考えて、最適解を導く必要がありますね。

iPhone の仕組みを理解しているわけではありませんが、専用の iPhone アプリとしてインターフェースを提供する方が安定する気がしています。もちろん、開発者の技術力次第ではありますが。

この辺も、実は Apple の狙い通りなんでしょうか？ハードウェアと、OS、操作インターフェース(概念？)は提供するから、あとは自由にしてね、と。不満があるなら、作っちゃいなよ、ユー、と。

iPhone に関する議論等を、ほとんど目に入れていないのでアレですが、App Store にたくさんアプリがあるのは、こういう事ですよね？ビルトインだけど、YouTube とか Google Maps とか、iPhone アプリにしたのは、端末の利用目的としてウェブ(ブラウザ)から切り出すべきなんて考えたのとは別に、検証段階で Safari に問題があったからでしょうし(多分ね)。

CSS などで iPhone 対応するのは、現状では無意味(効果的でない)でしょうね。少なくとも、ユーザが直接訪れる様な、利用目的がはっきりしている場合は、iPhone アプリを作って専用インターフェースを提供した方が、ユーザとしては嬉しいはずです。というか、そうでなければ、多分、使い(え)ません。Safari が不安定ですから。単品でちょっと見たいだけなら、いいんですけどね。

後、情報量が多くて雑然としている場合も、専用インターフェースが必要ですね。自分はともかく、携帯電話でのインターネット利用を普通に経験している、イマドキな皆さんには分かりきった事でしょう。ナビゲーション設計、導線設計も、PC での常識は通用しませんからね。

そんな事をつらつら考えてみると、(ウェブベース？でない端末ベース？の)RSSリーダーって、iPhone にこそ必要じゃないですかね。リーダーというか、RSS を利用してアグリゲート(これは既存サービスを再利用したい)して、蓄積した情報を効率的に閲覧できる仕組み。Safari でのインターネット利用が絶望的だと考えているので、じゃあ、ある程度目的を絞った汎用ビューワってのはどうだろうか、と。HTMLのレンダリングとか考えると、結局 Safari につながってしまいそうですが、そこはサーバ側で変換するなりしたらいいでしょうし(iPhone ではリクエストして結果を受け取ってそのまま表示するだけね)。

「検索エンジンを使って、Web にランダムアクセスしたい」とかいった要望には、完全には応えられないでしょうけど、それこそ、RSS 検索とか用意して API 経由で誘導したらよさそうな気がします。あ、Firefox の拡張で、RSS 使ってスタートページ作りますってのがありましたね。あれの iPhone 版とかないですかね。

App Store で探したら、この辺のアプリってありそうですよね。この辺のアプリはまだ探っていないので、あれば使ってみる予定です。

さて、携帯電話でインターネットを利用できる様になった頃に語り尽くされただろう事を、今更ながら嬉々として夢想しているこのごろです。

情報収集だけなら、PlaggerとGmail使えば十分かも。Plagger使ってリーダーの未読記事をGmailに送って、iPhone のメールアプリで読む、と。ある程度までは、メールを使っておけば、Safari 問題に対応できそう。

作者:

更新日:2008年9月20日 23時48分

このブログのホーム

着実に増えてる。。。

見事に晴れたので、予定通り健康診断に行ってきたわけですが、年々体重が増えてます。食べる量は増えてないのに。

やっちゃいけない体重の増え方ですね。

運動して、おなかが減って、自然と食べる。そんな生活に憧れます。

作者:

更新日:2008年9月20日 22時58分

このブログのホーム

困った。

まず、サクサク読めるUIを備えたPDFビューワが欲しい。アプリからPDFファイルを開いたときのビューワ、あれはひどい。Air Sharingを使って、macから転送したPDFを開いて読んでみたわけですが、読み続ける気力を根こそぎ持っていかれます。誤操作で先頭に戻ってしまったり、途中から読む方法が分からなかったり、散々です。

あと、ファイルの中央管理(?)の方法が分かりません。ファイルは、アプリごとに管理するしか無いんでしょうか。だとすると、一度macに転送して、改めて適当なアプリを使って転送する事になるんですかね。1つのマウントポイント(?)を使って簡単に同期がとれないと厳しすぎる気がします。

致命的なのが、突然のiTunes再生ですね。これは、周りで被害にあっていた人がいたので、そういう症状があるらしい事は知っていましたが、自分にも降り掛かってびっくりです。というか、そもそも、iTunesの終了というか、停止が無い(見当たらない)のが気に入りません。一時停止なんて曖昧なことせずに、男らしく(?)停止もしくは終了したいわけです。ヘッドフォンのジャックを抜いたとたんに音が鳴り響くと腰が抜けそうになります。

というかですよ、消音(マナーモードかな？)にしてるのに、iTunesでスピーカから音が出るのはどうなんでしょうかね。iTunesとは別の音量コントロールを触って勘違いしてるんでしょうか。正直、スピーカからiTunesの音を出す意味が分かりません。デフォルトにしておく意味が分かりません。むしろ、ジャック抜いたらiTunesが起動できないくらいでちょうどいいです。あ、そういう制御が可能になるアプリがあったら、いいですね。

と、文句たらたらなわけですが、基本的には気に入ってます。全体的に狭っ苦しい時代の携帯電話しか使った経験がないので、感覚的に使えて開放感があるiPhoneは凄まじく心地いいです。携帯電話の入力インターフェース(デバイス？)の進化を全く経験してないからかもしれませんが、こだわりを持ってUIにこだわっている風なappleがまた好きになっているところです。まあ、使い続けたら、結局iPhoneのソフトウェアキーボード(?)が使いにくく感じるのかもしれませんが。

そういえば、変な勘違いというか、ものを知らないというか、簡潔にいえば赤っ恥をかいたわけですが、無線LANルータなくても、iPhoneでWi-Fi使ってネットワークにつなげられるんですね。インターネット共有ってものがありましたね。仮想マシンでお世話になっているのに、思いつかないところは、さすがネットワーク音痴です。遺憾なく無知っぷりを発揮してしまいました。

一応、アクティビティモニタを使ってネットワーク状況をモニタした感じでは、LANを通っている様に見えました。ネットワークのセグメント(?)がどうとか、LAN内のホストにアクセスできるか、とかは試し無いので分かりません。あどほっく、覚えました。
Palm + Mac OS XでAdhoc WiFi インターネット接続

さて、結局、iPhoneで何をどうやって見ようか方針が定まりません。URLをメールして、そこをブックマーク代わりにするのがいいんでしょうか。普段、Safariを使わないので、ブックマークの共有も何もないわけです。後で読むとかを使って、gmailにスクラップをためておいて、それをiPhoneで消化するのがいいんでしょうか。何か、フリーで特別なフォーマットのデータファイルを扱うアプリケーションが出てきてくれませんかね。PDFがどうも絶望的な印象なので、上手い事索引などを用いてサクサク読み進められる感じを期待します。適当にHTMLなりTXTなりをそのフォーマットに変換できるmac用ツールもあると嬉しいですね。データフォーマットもオープンだと、あれこれいじる人が出ていいですね。なんてのが本当になったら、野良があふれて大変な事になるんでしょうか。PDFを上手く扱うアプリがあれば、それで解決でしょうけどね。

まったくまとまりませんが、使い始めて5日位での感想でした。

作者:

更新日:2008年9月18日 23時34分

このブログのホーム

【2ch】ニュー速クオリティ:「iPhoneっておサイフケータイ使えないじゃん」という問にAppleが回答
↑を思い出して、今日の帰りは iPhone で改札パス。

ジャケットが iPhone ジャストなので、横っちょが膨らんじゃってますけどね。そのうち、カードが曲がりそうな気がしますが、まあ、いいでしょう。

定期更新の時に投入口に入れられなかったら、そのときに、考え直します。

作者:

更新日:2008年9月18日 21時8分

このブログのホーム

メタクラス

class Object
  def metaclass() class << self; self end end
  def meta_eval(&blk) metaclass.instance_eval(&blk) end
  def meta_def(name, &blk)
    meta_eval { define_method(name, &blk) }
  end
end

001:>> class Object
002:1>   def metaclass() class << self; self end end
003:1>   def meta_eval(&blk) metaclass.instance_eval(&blk) end
004:1>   def meta_def(name, &blk)
005:2>     meta_eval { define_method(name, &blk) }
006:2>   end
007:1> end
=> nil
008:>> s = "hoge"
=> "hoge"
009:>> s.meta_def(:to_ss) { return "ss" }
=> #<Proc:0x0033e8ac@(irb):9>
010:>> s.to_ss
=> "ss"

メタクラスの使いどころ

001:>> table_name = 'samples'
=> "samples"
002:>> ActiveRecord::Base.connection.create_table(table_name, :force => true) do |t|
003:>>   t.column :value, :string
004:1> end
=> []
005:>> model = Class.new(ActiveRecord::Base) do |klass|
006:>>   def self.to_s
007:2>     table_name.singularize.camelize
008:2>   end
009:1>   set_table_name table_name
010:1>   reset_column_information
011:1> end
=> Sample(id: integer, value: string)
012:>> silence_warnings do
013:>>   Object.const_set(model.to_s, model)
014:1> end
=> Sample(id: integer, value: string)
015:>> model.create(:value => 'test')
=> #<Sample id: 1, value: "test">
016:>> model.find(:all)
=> [#<Sample id: 1, value: "test">]
017:>> Sample.create(:value => 'hoge')
=> #<Sample id: 2, value: "hoge">
018:>> Sample.find(:all)
=> [#<Sample id: 1, value: "test">, #<Sample id: 2, value: "hoge">]

作者:

更新日:2008年9月18日 0時30分

このブログのホーム

User-Supplied Identifier の怪 - Yet Another Hackadelic
ちょうどいい機会なので、便乗して復習させてもらった。

正規化を無視すれば、言い切っていいんだろうな、と思いました。

「認証を開始するために RP に提示する Identifier が User-Supplied Identifier」だと理解しているので、どこでどうなったとかは関係なさそうな印象です。エンドユーザが直接 RP のログインフォームに記入しようが、OP 経由で RP に教えようが、RP からすれば、認証を開始するための Identifier を受け取るだけでしょうし。

仕様書で定める用語定義としては、やや利用例(?)的な記述が目立ってしまった、という事でしょうか。それはそれで、ユースケース的なセクションをもうけたら良かったりする気がしますが、用語定義にまとめるのがすっきりするんでしょうかね。

ちなみに、先に正規化云々と書いたのは、User-Supplied Identifier は正規化されてなくても受け入れられるだろうけど、Claimed Identifier なんかは正規化されてなきゃ駄目なんじゃないかな、という事です。解説として、「User-Supplied Identifier は具体的に〜」と言うのは問題ないし分かりやすいけど、仕様としては(厳密に隅っこ突っついたら)間違いなんだろうな、と。

とまあ、正直、参照記事について肯定も否定もできる様な理解度ではないので、よけいな茶々を入れただけになってしまいました。が、復習の機会を得られた事に、感謝しています。

作者:

更新日:2008年9月17日 0時42分

このブログのホーム