例のブラウザにデータを覚えさせるための Cookie なのですが、HTTP Header でクライアントに渡すときに注意しなければならないっぽい。
最初、以下のように複数の変数を1度にブラウザに送りこんでみた。
Set-Cookie: hoge=fugafuga; fuga=hogehoge; expire=Sun Feb 3 05:09:26 2002 GMT;
このようなやりかたはダメみたいで、1度に一つの変数しか渡せないみたいだった。なので、複数の変数をクライアントに送る場合は…。
Set-Cookie: hoge=fugafuga; expire=Sun Feb 3 05:09:26 2002 GMT; Set-Cookie: fuga=hogehoge; expire=Sun Feb 3 05:09:26 2002 GMT;
と やらなければならないみたいだ。って、今まで知らなかったこと自体、はずかしかったりする。
普通の人は絶対に知らないと思うんだけど、ごく一部の Starbucks のお店ではミルクの代わりに豆乳を使う Soy Latteなるものがありまする。確か渋谷文化村通り店と、山手線内側のどこかの 2店だけの限定隠れメニューです。
試しに渋谷文化村の Starbucks で Soy Latte を頼んでみました。見た目は普通の Latte と同じです。ちなみに注文したところ、Soy Latte なんか注文する人少ない、というかメニューに書いていないようなモノを注文するもんだから、奥の倉庫から豆乳取ってきたりしていて、商品が出てくるまでに時間かかりましたなぁ。(約5分)
味の方なのですが…、コーヒーより豆乳独特の香りの強さが勝っていました。豆乳嫌いなひとは絶対に飲めませんなぁ。逆に牛乳苦手で豆乳ならオッケーな人ならイケるかもしれません。
ドンキホーテ渋谷で以下のブツ:
MEJA の方は矢井田瞳の「I'm here saying nothing」の Copy が入っていますなぁ。倉木麻衣の方は U.S. の方からの逆輸入。U.S. 市場向けなクセになぜか日本語の歌詞まで入っていたりするんだな。んでもって、歌詞カードとかの写真がモロ京都って感じで、Asian taste 抜群なだなぁ。
ひとまず Grip + Ogg で Ogg にして、XMMS なり Winamp で聞けるように rippingする。
Linux 用の Java (j2sdk) を Update するには、以下のようにすればオッケーみたい。
sudo rpm -Uvh j2sdk-1_4_0-rc-linux-i386.rpm sudo rpm -e jdk
j2sdk が jdk を Obsolete していないとか、ちとアレかな。そういう方針だったら別にそれでいいんだけどね。
何が何だかよぉわからんが、Servlet なるものをイジってみることにした。またこれよぉわからんけどTomcatとか言うものを入れてみた。ひとまず、このホストの 8080番で Web Server らしきものが動いておる。
この「何が何だかよぉ分からんが、ひとまず動かしてみる」とか言うノリの行動って、「何が何だかよぉ分からんが IIS インストールしてみる」とか言う行動とほぼ同等であって、セキュリティ的にはスンゲェやばいなこりゃ。
ひとまずリンク集だけでも作っておくか:
majordomo って light weight なんだけどカスタマイズしづらい。 ライセンスも「オリジナルからの変更点を明示しろ」みたいな風になっているし。 っつかー、Hook かけるところが全然ないじゃないか。 「オリジナルからの変更点..」っていったら「ほとんどのコード捨てますた」って言いそうだな。
FML はちと重そうだし、いつまで Perl 4 に依存したようなコードだし。 そのくせ Perl 4 では動きそうもないけど。
なんかまた意味不明な文章がのっている。
というのは、この修正によって、IEでは、HTTPとHTTPSのURLにユーザー名とパスワードを埋め込む機能のサポートが打ち切られるためだ。このクリアテキスト認証のサポート打ち切りは、偽りのサイトを仕立ててユーザーにクレジットカード番号や社会保障番号などの個人情報を提示させるトリックによく使われるURL詐称の問題への回避策となる。
クリアテキスト認証ってなんだ? ネタ元として示されているマイクロソフト サポート技術情報 834489 には、URL にユーザ名を入れる方法のサポートをやめるということがかいてあるが、クリアテキスト云々については書かれていないように読める。 どうやら、クリアテキスト認証は普通に使っている Basic Authentication とも違うみたいだ。
原文のIE Patch Could Disrupt E-Commerceは、こうなっている。
The withdrawn support for clear text authentication effectively provides a workaround for the URL-spoofing flaws that are commonly used by scammers to mask fake sites and trick users into giving up sensitive information including credit card and social security numbers.
確かに「clear text authentication」と書いている。 んで、MS の元の文章を読んでも "clear text authentication" なんていうことは書いていない。
一般的に clear text authentication と聞くと、パスワードを平文のまま stream で流すっていうのを連想するんだろうけど、今回の文章 (原文) を書いた人には、そのような意識がないのかもしれない。
普通に考えれば、電子出版のほうがいろいろなコスト的には強いよなぁ。 紙媒体だと、紙に印刷+製本のコストはかかるし、全国の書店に並べる配本のコストもあるし、返品・売れ残りの廃棄に関するコストもあるし。 最適化を求めたら、ほとんどの書籍が電子書籍になりそうだ。 ただ急激な世代交代は、変化に伴う痛みや不便さも一気に来ますからね。
現在出版をしている出版社や著者にとってみれば、現状では小売販売をする書店、流通業者の存在があってこそ成り立っている。 商売は取引相手も儲かって利益があがってこそ成り立つ。 彼らの利益にならないことを始めれば、彼らから縁を切られる、ようは書店や流通が本を売らなくなる、可能性だってある。 既存の販売網も大事にしたい、っていう思いはある。
今回の場合、電子書籍の流通を始めたAmazonに対して商品を卸さない、という対抗に出たのだろう。 特定販路に商品を流さないのが良い・悪いの議論はあるだろうが、既存の販路も大事にしたい出版社としては行っても仕方ないことだよなぁ。
ってところで、販売価格の差を小さくして、電子書籍へのユッタリとした移行をしましょう、ってのは、なんとなく互いの妥協点・合流点を見つけたんだろうな、と思いました。
んで、あっちこっちにある書店は、今後どうするんだろうなぁ。 既存メディアがなくならないのと同じように消えはしないだろうけど、減るんだろうなぁ。 意外と商店街でひっそりと10畳ぐらいスペースで営業している土地建物持ちの本屋さんが長生きしたりしてね。
あと、たとえば子供向けの絵本や、写真が豊富な雑誌類、地図、観光案内などの本は、これからも本屋さんで紙媒体で買いたいな、と思う今日この頃。 あとは「紙に印刷しないと読めない」な方にとっては、これからも紙の書籍は必要なんでしょうね。 僕の場合、パソコンで読んだ方が速かったりしますがw
・ よこい [宇jひbjtぐいshlhrtgfけsろl erpogjisphbsthgんpdぅghjぴrshgtrs宇gひえsj..]
・ Kiichiro (knaka) [↑何語? あー、今年も食いっぱぐれた…。]
・ まさる [猫が描いたような文章だなw]