  |
はてなキーワード: レスポンスとは
やっぱねぇ、初めからこうなるって事を考えるべきだったんだと思う。
企画担当になったのはいいが、企画関わらないサークルの他の人は企画に興味ないんだろうな。なに投げてもレスポンスなし。
先輩曰く「前からそうだった」らしいが、もうそろそろこの体質どうにかしたほうがええんとちゃう？
他のサークルのこと知らんけどさ、学園祭に出展するサークルが自己満なぁなぁでやってる状況はまずいだろ常考。
自分で蒔いた種、他人がくれた種とは言え植えたのは俺だ。俺が責任取らないといけない。
それでも…サークルって連帯責任やんなぁ。まさかこれから学園祭でやろうっていう企画が個人責任だなんて思っちゃいねぇよな？
終わってから「今年の企画担当はダメだったなぁ」なんて言うのは勝手だ。ただな、サークルのヤツが言うのは正直ゆるせねぇ。
上回生ならこれ以上企画関わること無いからって理由で逃げるだろうけどさ、てめぇら後輩の土壌潰すことになり兼ねないのわかってんのか。
そんな意味も踏まえて、まぁ今年は最低のモノができあがるでしょう。企画担当の俺が言うんだから間違いない。当然後輩には以降辛い状況が待ってるでしょう。だからこそ、俺はどう責任を取るべきか。
# ただな、後輩に仕事頼んで返ってこなかったこともあるから少し「ざまみろ」って思ってるところもある。まぁ狭義の自己責任だ。
安倍さんの辞めない姿勢、俺は少なからず評価している。辞めて責任取るのは正直「逃げ」だ。一番やっちゃイケナイコトだ。
とは言うものの、それ以上そのポストに置いちゃ後々もっと酷いことになるから、辞めることが最善の選択なのかもしれないが。
だからこそ、安易に「辞退」って選択肢を出しちゃいけないと思う。刑務所に入れるより奉仕活動。晒し上げでも構わないが社会の利にならんからなあれは。
とまぁだらだら書いてるこれも意味があるのかねぇ…俺が4回生になってサークル辞めてから、この内容を内部告発ちっくに流したら少なくともサークルと学校に影響出るでしょう。サークル潰しかねない影響がねｗ
そんなこんなで、匿名ダイアリー。気兼ねなく書けるんだが、これ、２ちゃんとあんま変わってなくね？
■X-Reproxy-Cache-Clear できる Perlbal プラグインCommentsAdd Star
■[Perl][CPAN][Perlbal] X-REPROXY-CACHE-FORを使いたい人向けショートBK
X-REPROXY-CACHE-FOR ヘッダが Perlbal に(というか Perlbal::Cache に)どのように解釈されるかというと、
1467 sub add_to_reproxy_url_cache {
1468 my Perlbal::Service $self;
1469 my ($reqhd, $reshd);
1470
1471 ($self, $reqhd, $reshd) = @_;
1472
(snip)
1484 my $hostname = $reqhd->header("Host") || '';
1485 my $requri = $reqhd->request_uri || '';
1486 my $key = "$hostname|$requri";
1487
(snip)
1496 $cache->set($key, [$timeout, \@headers, $urls]);
1497 }
こうなってる。ここで、
Perlbal -> mod_perl -> MogileFS
こんな風に、フロントに Perlbal, バックエンドに mod_perl ハンドラでも置いて、その裏の MogileFS とやりとり(をあんまさせたくないので Perlbal に直にキャッシュさせたい)という構成を考える。
この場合、
つまり、
X-REPROXY-CACHE-CLEAR: /artwork/12345
というヘッダを mod_perl から Perlbal に返す必要がある(host は補われる)
この /artwork/12345 というリクエスト URL は、 mod_perl 側から直に参照できない。
mod_perl ハンドラを例えば以下のような conf であてていたとすると、
<Location /example/artwork>
PerlHandler Example::Artwork
</Location>
RewriteEngine On
RewriteRule ^/artwork/(.*) http://127.0.0.1:8080/example/artwork/$1 [P,L]
ここで $r->uri をとると /example/artwork/12345 となり、これをそのまま X-REPROXY-CACHE-CLEAR で返しても Perlbal::Cache がキャッシュした key とは違うものなのでキャッシュを破棄できない。自前で $r->uri を split なりして、 /artwork/12345 を、 Rewrite される前の URL を知る必要がある。当然、どんな RewriteRule かに依存するので一般的な実装はあげられない。 Rewrite しなければもう少し話が簡単になる。
要は、
と、それぞれ意味の違った URL (key になるもの)がいくつか存在して、どれがどれやらわからなくなってしまうので、ハマりどころが多い。ありがちな(というか俺がやった)ミスとしては、 CACHE-FOR でキャッシュした状態で MogileFS からファイル実体を消してしまうと (mogile に突っ込むときの key はまた別に digest とかで作ってあったりすると余計に混乱することうけあい) Mogile にはもう存在せず、したがって mod_perl にはどうしたって知りようがない URL を Perlbal がキャッシュしていて 503 を返しつづける、という状態になってしまう。それから、キャッシュを自発的に消したいときというのはもともとキャッシュしてた URL (Mogile 上でのファイルのありか)が指し示すファイル実体を消したいときなので(実体がないものをいつまでもキャッシュしているのは困る、という理由)当然実体そのものも消すわけだが、
こういう手順でつくらないといけない。この URL は ACL を厳重にしておかないと、全ての artwork に対応するキャッシュ破棄用(つまりファイル削除用) URL を GET されまくってファイルを消されまくってしまうので非常にまずい。
我ながら乱雑で要領を得ない文章だと思うけど、こんなものでもないよりはあったほうがこれから同じことをやろうとする人にとっては多少の助けになると思うので走り書きのままで公開する。こういう、どっかに一言書いてあれば5秒でぐぐって済むことを何時間もかけてやり直すのは人類にとっての時間的損失でばからしいので、適当に間違ってるところとかを修正しつついろんなブログとかに転載しまくって世に広めてください。
アンテナに入れてたりちょくちょく覗いてたりするブログがしばらく更新がなくなって、それ自体は大して気にすることはないんだけど、
久しぶりに更新したと思ったら、たいがい「書いてなくてスイマセン」「mixiばっかり更新してて」「mixiでは順調なんですけど」なんて書かれてて。
こういう文言を見ると一気に淋しい冷めたような気持ちになるのね。
別にmixiを嫌悪してるわけでもないし（自分もやってる。日記は書いてないけど）、その人がどんなmixi生活を送ってようが関係ないし、わざわざmixi内を探してまで見知らぬその人の日記や文章を読みたいわけじゃないんだけど。
ただなんか、「あーこの人は忙しくって書けなかったとか、何か理由があってネットを離れてたわけでなく、クローズドな（しかもある程度レスポンスが期待できるだろう）場所を選んで書いてたんだ。」というへんに歪んだ気持ち。自分は根っからのブログさんだから、身近にこうした感覚の違いを目の当たりにしてちょっとショックになるのかもしれない。
自分の影が薄いと言うのは確かかもしれない。
勝手に期待しているだけなんだけど、ドライな人が多いように感じるんだよね。(自分がドライだと思われているというのもあるけど)
何の理由もない関係を続けることの難しさというか。そもそも連絡取り合って関係を続ける意味が有るんだろうかと考えてしまう。自分が関係を続けようとすることが、相手からのレスポンスがあるかないかで決めてしまうことも何か違うような気がして、割り切れずにいて。
自分は誘ってもらったら誘い返すようにしているんだけど、そういう発想がない人とは、よっぽど気がある人じゃないと、もういいやと思ってしまう。こっちから働きかけることを、労力と感じてしまう自分に一番の問題があるのかな。
del.icio.usは何故はてなブックマークのようにならないのかを少し考えてみた。
結論は第一に、個人のタグとコメントが分割されて表示されること。第二にブックマークしたユーザが多すぎる場合は全員のタグを確認する動作にワンクリック必要な事、第三にユーザーアイコンの有無だった。
第一の問題が少し大きく、タグが個人のコメントと結びつく時、その最小単位の言葉で構成されるタグの含蓄性と、第三のユーザアイコンがなんらかの意味を持たせてしまい、そのタグとコメントがなんらかの重みを持ったものになってしまっている現状があるのかなと。
問題発生の遠因のように考えられ、リンク先ページへのタグ・コメントを集積する場のデザイン（UI）はそのままそのWebサービスのアイデンティティなので、単純に改善が行なえるわけではなく、デザインの変更は多少なりとも大きな爪あとを残すので難しいところ。ページデザインがそのサービスに影響を与えるのは増田をみてもわかるように、一つ考えておきたい点だと思うので考えてみた。
diggなんかはどうなっているのだろうか。はてブはdiggのように今をメインに扱う指向も有していると思われるので。それと同じものを持つWebサービスとして追加でdiggの印象を思考してみた。
個人的に、diggはdiggで色々な問題があるけれども、スレッド型表示と、発言者に明確なレスポンスが送れ、そのレスポンスがちゃんとその対象とするコメントの下にくっつくページデザインの作用で、ネガティブコメンターに対し冷静なコメントがなされる事があり、ネットイナゴ現象・２ちゃんねる現象までは起きていない感がある。
蛇足だが、diggのモデレート機能もそこそこ機能しているようで、パリスヒルトンの記事があがった時にはビッチは刑務所でレイプされてろよなんてコメントがちゃんとマイナスモデレートされて表示にワンクリックが必要なようになっていた。そのコメントの後に付いた、パリスなら喜んで腰を振るだろうなという発言に笑ってしまったのは秘密である。
その記事でも、ちゃんと賛否両論の意見があり、行き過ぎたコメントには釘を刺す反応がなされていた。単純な言いっぱなし、単調な意見のスクラムだけにならず、何気に機能してるなぁと思ったものである。
メールの件名の頭に付く「Re:」は Response の略じゃないよ！
わかりやすい説明の例
http://www.wdic.org/w/WDIC/re（re - 通信用語の基礎知識）
ラテン語の名詞res(レース)「こと・もの」の奪格re(レー)から英語の前置詞に転じた。なお、ラテン語では名詞の一変化であって前置詞ではない。
例えば、メールの返答の件名(Re:〜)や、掲示板のレスポンスタイトル等に使われる。しかしそもそも省略形ではないので、このRe:はreplyの略でもresponseの略でもない。
RFC ってのは、簡単に言うと「インターネットで使う技術の細かい作りについてちゃんと決めて、みんなでその決まりに従おうね！」というもの。じゃあ RFC 2822 について見てみよう。
http://www.puni.net/~mimori/rfc/rfc2822.txt（Internet Message Format）
The "Subject:" field is the most common and contains a short string identifying the topic of the message. When used in a reply, the field body MAY start with the string "Re: " (from the Latin "res", in the matter of) followed by the contents of the "Subject:" field body of the original message.
「Subject:」フィールドはもっとも一般的で、メッセージのトピックを識別する短い文字列を持つ。返信で使われると、そのフィールドボディは「Re:」（ラテン語の「res」、「??について」から）で始まるかもしれない(MAY)。
きちんとメールに関する標準規格文書に明記されているんだよ！
これら二つの記事をまとめると、「Subject: フィールド（件名欄）にはラテン語の res （レース）が変化した re （レー）を使う場合もある」ってことになる。繰り返すけど reply や response は関係ないから注意してね！
さて、それじゃあ次に他の辞書ではどうなってるか見てみようね！
http://dictionary.goo.ne.jp/search.php?MT=re&kind=ej&mode=0&base=1&row=4（Re: - goo 辞書）
Re:
goo 辞書さんが出す情報（EXCEED 英和辞典の内容）まちがってるよ！ これってどこにメール送ったらいいのかな。三省堂に電話しなきゃだめ？
訂正しないと RFC 2822 でちゃんと明記したひとがかわいそうだよ。だって「メールの頭についてる Re: はラテン語からきてるんだからね！」って言ってるのに「英語の reply だよーんあばばばば」なんて言われたら、「最初にラテン語だっていったのに……」って悲しくなっちゃうよ。ひどいよ。
辞書は言葉に対する一般的な認識を列挙するものだってことはわかってるよ。言葉が変化するものだということもわかってる。俗説を書くなとも言わない。でもね、Re: の場合は最初にきちんとした定義があったんだよ。俗説は俗説なのであって、定義を超えることはできない。
たとえば円周率は 3.14 って学校で習うけど、これは小学生に記号を使った計算は難しいので、円周率に関する計算では記号を使わずに 3.14 ということにするってだけの話で、別に円周率が 3.14 になったわけじゃない。円周率はπなんだよ。同じように、Re: が reply や response の略称であるという誤った俗説がいくら広まったところで、Re: は ラテン語からきてて、その事実は全く変わらない！
俗説を書くなとは言わない。だけど俗説は俗説だと明記しないとだめだよ。本来の意味とは全く無関係なんだから。この三省堂 EXCEED 英和辞典の内容は、俗説が本来の意味であるかのようにしか読めないよ。
勘違いすることはわるいことだと思わない。科学技術者だって誤用ぐらい平気でやる。でも科学技術における、言葉に対する一般認識と正しい意味の差が理解できない人は、科学技術の用語について述べるべきではないよね！ 少なくとも指摘を受けたら訂正するべきだよ。
というわけなんだけど、三省堂 EXCEED 英和辞典の件はどこに連絡すればいいのかな。
http://dictionary.sanseido-publ.co.jp/support/question.html（辞典に関するお問い合わせ - 三省堂書店）
ここでいいのかな。ちょっとメール送ってくるね！
次はアルクだよ！
RE
正しかったので問題ないです！ でも、〈ラテン語〉って書いてあるせいで、なんかラテン語の前置詞みたいに見えるね。最初の「re - 通信用語の基礎知識」にも書いてあったように、ラテン語の前置詞じゃなくて英語の前置詞だよ。まあこれはアルクの表記スタイルを把握できていない僕がわるいんだけどね！
JASRACのえげつない所業がネットで叩かれてるのをよく見るが、
これが俺にとっては本当に不思議なのだ。解けない疑問というか。
同じような仕事をしてる奴ならわかってくれるんじゃないかと思うんだが、
JASRACの担当者のほとんどが、ソフトで明晰で融通が利く有能な人間だ。
レスポンスは早いし、規定のなかでできるだけ安くなる方法を教えてくれたり、
そういうJASRACと、ネットで叩かれているJASRACが同一団体というのが、どうも実感がわかない。
銭ゲバなみの回収とか、不明朗な分配とか、そういうのが嘘だといってるわけじゃない。
ただ、JASRACは２つの顔をうまく使い分けていて、
ソフトな対応というのは敵に回さないためのマスコミ対策という面もあるのかなと思う。
そういうソフトな面があることを知らないちゃんねらたちがガタガタ騒いでるだけでは、
JASRACの地位なんてビクともしないだろうよ、ということなんだ。
http://anond.hatelabo.jp/20070318175250
どなたか知らないが、感謝する。
人類の発展性において、全く現時点は立ち止まるような状態ではないと思う。そのレベルたるや、ゲームで例えるならば可能性がLv100くらいとしたら現在Lv3くらいではなかろうか。でも社会的な雰囲気はすでにLv70を超えて、そろそろ飽きてきたかなという倦怠的な雰囲気すら感じる。
そもそも欲望というものは、外界の環境に対して生きる方向に最適化された内的なエネルギーのベクトルなのだが、今の現状は、それを満たすだけのフィードバックが現実以外で簡単に手に入れることが出来る。それは、まだ欲望フィードバックシステムを作りきっていない子供にどういうように作用するかは明らかだ。
環境が全ての欲求を満たしてしまえば、欲望を持つ必要が無くなる。つまり、満たされたという偽りのフィードバックで満足してしまい、それ以上手を出そうとしなくなるはずだ。それが今の日本の現状。
衣食住とあらかた欲望は埋まってしまっている。飢えることに飢えている状態だ。「本当に欲しいもの」が欲しい、欲しいものを探しているなどの言を高校生??大学生などが言うが、あれは欲しいものが無いのではなく、飢えたことが無いのだ。渇望とかギラギラした欲望が無いのだ。それは、本当に飢えないと手に入らない。でも、安定は崩したくない。だから、何時までたっても手に入らない。
衣食住という基本的な欲求だと、もう満たしてしまった。なので、次の欲求にフォーカスする必要が有るのだろう。限界が無く、生産的なもの。自分の知りうる限り知識欲と創作欲くらいしか、思い浮かばない。知識欲を飢えさせるのはどうすればいいんだろう。創作欲を渇望させるにはどうすればいいんだろう。
日本は、偽快感レスポンスを作るのが一番うまい国だと思う。うまく利用すれば他国を骨抜きに出来るが（そんなことしてもというのは別として）、自家中毒になってる状態だ。うまく次のレベルのフィードバックシステムを作れればいいのだが・・・。
ヤフーはどうしてこういい加減なのか
１ユーザーからみても
法人相手としても
子供過ぎる
顧客を満足させるとかという意識はないのか
法人の中の一サラリーマンとして働いていて
Yの法人向けシステムを使って業務を行うのだが
そのレスポンスが悪く
かつみづらく
わかりずらい
ただうちのかいしゃの飯の食い種であることは
間違いないのだが。
内部側で多くの情報を持っているようなつくりにはとても見えない。
1日単位増えても多くても2000行程度増加と予想。
あまりにしょぼい。
90秒近く待たなければいけないのはどうにかならないのか。
ようやくデータがはいっても、こちらの想定した数には追いつかないこともふえてきている。
ただの愚痴です
多分世界は、あなたが思っているよりもずっと馬鹿が多くて、たくさんの甘ったるいだけの友情や人間関係や馴れ合いにあふれていて、ほんの少しだけの悪意の無い愚痴が存在するんですよ。谷（もしくはあなたの部屋のドア）の向こう側かもしれませんけど。
私もこの文脈で納得がいった。多分世界は貴方が思っているよりもずっと賢い人が多いと思う。などという優越感ゲームは不毛なので華麗に相対化しておしまい。それよりも前半部に対するレスポンスを誰かして欲しいのだけど、どうも都合の悪いことは返事くれないなみんな。
じゃああんたは結婚したとき祝儀もらっても嬉しくないんだろうなあ
俺は俺がそうなったときそうしてくれたら嬉しいから
そうしてるんだよ
コンセンサスとかどうでもいいの
祝われる相手が嫌だって言ったらしないし
私は社会的なコンセンサスの話をしているのに、貴方は終始自分の話をしている。自分がそもそも最初のエントリの趣旨を理解できていないことを自覚すべき。その上でどうでもいいのなら絡まないで欲しい。私は披露宴マトリックスというマクロな話をしているのであって、ミクロな話はしていない。
私は結婚したときに祝儀をもらえれば嬉しい。自分が幸せな時に人に幸せだよというのは恥ずかしいのでしない。その問題と、「披露宴、二次会をするのが当たり前となっている（＝社会的コンセンサスとなっている）」事実を問題化することは全く別の問題だ。
私に反論したいのであれば、以下の設問に答えなければならない。
立ち会わない形で祝うことを選択できないのはおかしいとは思わないのか。貴方のように祝儀をあげて時間を潰して結婚式に出て「おめでとう」という形式をなぞらなければ、本当に祝ったことにならないのか。
これ以上論点がずれそうならばもうレスポンスはしない。
否。君がanond:20070215153329で表した反応は、「その発想」がコンセンサスに基づいているという決め付けだ。コンセンサスの可否を問うているか否かとは関係が無い。
コンセンサスの可否を問うことと、そこから娯楽感を得ている者が全てコンセンサスを経由していると決め付けることは同義ではない。よって勝手に無効化すな。
ならば初めからそういう風に問うべき。貴方がやったことは、私の発言を一般化し無効化しようとする試みで、私はそれを再度無効化しただけの話だ。
「その発想」がコンセンサスに基づいているという決め付け
そもそもanond:20070215152515は当初提示されていた「コンセンサスの可否」の問題を、ミクロなシチュエーションに矮小化し、正当化しようとした。既にこの時点で議論は本題から外れている。なので私はanond:20070215153329で議論を元の問題へ吸収し、その後本題へ戻すことに成功している（anond:20070215155624）。よって私が「決めつけ」を行ったことはいわば戦略的な要請によるもので、いささか乱暴な方法ではあったがご理解いただけるだろうか。
「社会的コンセンサスと自主性」という問題はまだ別の深いテーマなので、本題からそれるのを避けるべくやらない。その後この話を続けるのならもうレスポンスはしない。
