リソースなのかRPCなのかREST魂ってのはありそうだな。ぶくまこめんとを眺めて思った。complexTypeとか出てきてること考えると、SOAPツールキットみたいなものを使って実装したんじゃないかと思える。すれば、実装の考え方はRPCだろうし、エラーコードはその関数の実行結果であって、関数呼び出しのレイヤーの結果とは別にするのは素直にみえる。なくてリソースの取得と見ればステータスコードを使えというのはもっともだ。RPCなら専用クライアントがあるのが(暗黙の)前提となるから、話は合うのだが、その一方で、そんなものなくても利用できるんだから(+多分、そんなものなしで利用してほしいと考えているようにもとれる)、だったらRPCとしての実装じゃなくて、リソース取得としての実装にすれば良いじゃんというのももっともだ。これって、結構、おもしろい問題だな。#自分で想像している以上に、自分が貴族的に考える(エラーコードは別じゃん)ことに新鮮な発見があったので、細かく書いてみた。pResult);問題というのがあって、fooのように実装するか、barのように実装するかというのが問題だった。一般論(MSの推奨だと思う)としてはbar実装をする。S_OK;}でも、おれはこれはくだらないと思って、foo実装が多かった。}}ミソの部分でIErrorInfoを作れるからだ。これに相当するのがレスポンスボディ部のテキストということなんだろう。すると、実際にはボヘミアンな考えをしてたってことだな(むしろ、その後に貴族化したらしい)。(追記:ちょっと違うな。呼び出し失敗は呼び出し失敗ということと、例外を使うと付加情報が多いことが理由だから、こっちはやはり意味を重ね合わせてるようだ)ちなみにfooとbarを呼び出すクライアントのコードは次のようになる。日曜は映画の日なのでカリブの海賊を見て来た。[DVD](ハンス・ジマー/ジェリー・ブラッカイマー)子供がはまりにはまっているんだが、1と2は見てないので、どんなものなんだろうか(子供はテレビで見てた)。なんか、スターウォーズの4〜6で、主役の男女よりもハンソロのようなアウトロー風味の風来坊が人気抜群で、2作目の最後では敵に捕らわれるわけだが、3作目でちゃんと主人公たちに奪還してもらえて、みたいなところもあったりするんだが、そのくらいスターウォーズは良いフレームワークを提供してるってことなんだろうか。それにつけても、食べ物じゃないものを人はどうしてああも気持ちが悪いものとして描くんだろうか。昆虫を食べない人たちは、昆虫を気持ち悪く描くし、鶏肉を食べない人たちは、鶏を気持ち悪く描く。鯨を食べない人は、鯨を悪魔として描く(船長の片足食ったり、木の人形を飲み込んだり、ヨナまで呑み込んでしまう)。他人を受け入れがたい人たちは、まずは人間を食べるところから始めればよいのではないだろうか。すれば、気持ちの悪いタコ船長じゃなくて、とってもかわいいオズワルドとかタコのはっちゃんみたく見えてきて親しみがわくだろうから。リソース/RPCクライアント側に立てば、実装がWebアプリケーションかWebサービスか静的なファイルの返送かはまったく関係ない。いうか、世界系なんだから、そんなものを気にしてもしょうがない(逆に言えば気にしなきゃまずい方面はあるし、その場合は、クライアントは当然のように必要になってバグが増える(ということはあり得ないから、そのあたりはノイズだな))。リクエスト出す側に軸足を置いてみるのか、それとも、サーバーの実装方法によってレイヤーが違うんだから、それぞれのレイヤーごとにきちんとエラーを返さなきゃだめじゃん、とレスポンス返す側(というより、両側そのもの側)に軸足を置いてみるのか、の違いのようだ。すれば、貴族とボヘミアンっていうよりは、キュロット(パンが食えなきゃ菓子食いな)とサンキュロット(おれたちに食い物を寄こせ)というほうが適切かも(元の分類方法は別にして)。なくて王の立場(飯の確保と輸送路の確保と輸送手段の確保と輸送計画と......飯が置き去りにされてしまったり)かも。すげぇ発見こりゃいいや。Silverlight。いうか、この歌はシルバーライトの歌だったのか。アイアイアイアンパイーソンアイアイアイアンルビーィーィーィーいろんな言語でオフショアだyo!シルバライット、シルバライット!Moonlightより、ポップで好きだ(でも、もう2度と聴かないけどな)。追記:いや、もう4回くらい聴いてるけど。(今日は午後からイベントなんで会社に行ってないのだった)惜しみない称賛。詳細を教えていただけないですか?あと、RubyLife.exeは、ASRのsamplesに入っている、ScriptControlを利用してRuby本のLifegameを自分のフォームに描画するVBのプログラムです。お金はモチベーションになるよ中国の言い回しに親子三代が「贅沢に暮らせる」金額というような表現がある。現在の日本円に換算するとざっと、最低8億円くらいだろうか(軽く試算したが、ちょっと足が出るような気もする)。1年間死ぬほど働いて成果を上げたら成功報酬が8億円と言われたら、おれだったら確かに死ぬ気ではたらくよ。7億9千万円程度じゃいやだね。ほかの人も同じか、もう少し高く勘定してるかも(9億円とか)。それが労働価値より高すぎると考える程度の端金しか出ないんだったら、そりゃモチベーションにはならないだろうなぁ。#金銭って絶対価値でしか考えてもしょうがないように思うが、そこを相対的な価値をもって成功報酬にしようとするのは間違ってるように思う。09:53)そうか、食べちゃいたいほど可愛いわけだ。10:11)自分はずっとfooスタイルで書いていました。いうかbarの方が一般的なんですか...。メリットがよくわからんとです。10:31)>barのメリット<br>メリットじゃなくてプロトコルです。<br>LRPCやDCE/RPCのレイヤーのエラー(マーシャルのエラー、セキュリティエラーなどいろいろある)などの非機能要件に当たる側のステータスがHRESULTで、アプリケーション処理のエラーは別途アプリケーション側で定めるってことです。そもそもHRESULTは戻り値ではないわけで(値を戻すのは[out,retval]属性の引数)。メリットじゃなくてプロトコルです。ありがとうございます。<br><br>そういう意味でいくと、自分は全部ごっちゃにしてHRESULTを使っていました。HRESULTのエラーコードを拡張して、アプリケーションのエラーコードを追加して、どこかのリソースファイルにエラーコードに対応するエラーメッセージを書いていたような気がします。<br><br>個人的にはアプリケーションエラー用の戻り値を、エラーが予想される全てのメソッドに定義するのはちょっとゲンナリすると思うし、コードの可読性が低くなるような気がするので、(プロトコルというのは話としてはよくわかるのですが)やっぱりfooスタイルを使ってしまいそうです。11:11)>HRESULTのエラーコードを拡張して、アプリケーションのエラーコードを追加して、どこかのリソースファイルにエラーコードに対応するエラーメッセージを書いていたような気がします。>やっぱりfooスタイル<br>で、貴族的にかっちりやるにはMFCの方法のようにHRESULTを返すレイヤーを隠してアプリケーションとRPC層を区別すべきなんだろうけど、直接インターフェイスを実装するATLの方法を使うってところが、ボヘミアン風味かな、と思ったということでした(が、元々HTTPなものをRPCから元に戻すRESTと違って、元々RPCなものを普通の関数として実装するのは単に野蛮人な方法かなぁとか(別に反省はしないけど)気付いたので、それは違うな、と)。11:14)つまりわたしは、このような野蛮人である、と。20:47)>だから、他人を受け入れがたい人たちは、まずは人間を食べるところから始めればよいのではないだろうか。<br>なんとも人を食った意見ですね。21:33)なにもそこにつっこまなくても。21:51)うちのかみさん曰く、愛おしいものは食べてしまいたくなるそうで、ハムスターとかは「食べてしまいたいぐらいかわいい」のだとか。自分には中々理解しがたい感覚ではあります。なると好きになりますよね。<br>好きになるとあばたもえくぼで可愛く見えると。<br>ただ、あの連中ははなからタコ食べないじゃないですか。気持ち悪がって(多分)。<br>日本だと、たとえば蛆虫とか(食べたことないけど。蜂の幼虫は食べたことあるけど)。<br>だから、まず食べる前に、それが可愛い(というか気持ち悪くない、でいいんだけど)ってのが来なきゃだめかなぁと。