トップ «前の日(05-06) 最新 次の日(05-08)» 追記

2002|01|02|03|04|05|06|07|08|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|02|03|04|07|

2002-05-07

_ Yahoo!オークションで、Yahoo!社員による落札価格操作疑惑

Yahooトップページでマグワイアのユニフォームが出品されました。落札価格は、4301000円です。それだけの価値はあるのかも知れませんが、落札したのは、Yahooの人間です。当然、主催者、関係者は激怒したと思いますが、屈服したと思われます。再度、出品すえば、主催者、関係者が疑われます。落札ID=auction_test1,,,,そのつながりでID=mineki_yashiro,,,,,,y_charity_auction,,,,,,なんと、auction_test1とy_charity_auctionは、同じ人物のメールアドレスだったようす。Yahooの言い分は、テストIDをオークションには反映されないものと勘違いして、ある人物が入札したので、次点の方に権利を移して欲しいと終了後にメールが来たそうです。このメールは、次点の方から5番目ぐらいまでYahooのメール付きで出されたようです。しかし、勘違いで、430万円を落札するでしょうか?このチャリティの関係者は、目玉中の目玉が、今も残っており困っているようです。Yahooがオークションをぶちこわしてどうすんだ!価格を自身で吊り上げ、PRしたかったのか?それとも本当にミスだったのか?どう思います?
お世話になっております。
Yahoo! JAPANの××でございます。

この度は私にこちらのメールが届きまして、おかしいなと思いながら調べてみますと弊社側でとんでもないミスを犯していることが判明いたしましたので、取り急ぎご連絡させていただきます。

実は今回最高落札者になっておりましたID: auction_test1 は弊社オークションにて管理しているテスト用IDでして、登録メールアドレスが私のアドレスになっております。 実はこのIDを弊社の者にテスト用として19日に渡したのですが、この者がテスト用だから本番に反映されないと思い込み実際にこちらのIDを使っていくつかのオークションにて入札を行いそのままにしていたところ、最終的にこちらの商品を落札してしまったという次第であります。
大変恐縮ではございますがこちらのIDの入札を削除していただき、落札権利を次の方にお譲りいただければ幸いでございます。
この度は弊社側の失敗によりこちらのオークションに大変ご迷惑をおかけしてしまい申し訳ございません。

まずはメールにてご報告させていただきます。
どうぞ宜しくお願い致します。

××

あちこちで話題になっているYahoo!オークションの社員による落札価格操作疑惑。さすがに「auction_test1」なんてIDで操作をしようと思うバカはいないだろうから、これは本当にミスなんだろう。

でもYahoo!オークションは、有料化の際に「出品者は、落札価格の3%を落札システム利用料としてYahoo!に支払う」という仕組みを用意しており(5/15より施行)、しかも、「落札システム利用料は毎月20日までに終了したオークションの月末時の落札額を基準に集計した料金の合計を翌月請求させていただきます。 」となっているため、イタズラで高額落札された場合にも落札金額の3%を支払わされかねないという、利用者に非常にキビしい内容となっている。ただでさえそのあたりのシステムの練られ方がアヤシイ状態なのに、いくらミスとはいえ高額目玉商品の落札に社員が関わっていたという事態(がばれたの)に、関係者数名にメールでお詫びしておしまいにしようってのはどうだろう。

もともと有料化システムの怪しさがクリアにならない限りは利用する気になれないでいたけれども、こういうことがあったんじゃシステムが(表面的に)まともになったところで今後利用する気になれないなー。ソフトバンクはまだ若い会社だからこういう正常系じゃない事態に対する対処法が甘いのね(Yahoo!BBしかり)、と考えてあげることもできるけれども、あれくらいでかい会社だったらさすがにそういう言い訳も一般的には通らないだろうし。

Tags: watch

2003-05-07

_ Gartner Column:第91回 いいとこどりアーキテクチャのNUMAとRAC from ZDNet (13:49)

メモリの大部分をDBアクセスが利用しているような場合ならば、NUMAみたいなアプローチで十分高速に動作させることが出来るのかな。エンタープライズ系でNUMAとRACは抑えておいた方がいいキーワードっぽいな。

_ レコード会社、海賊行為“攻撃”ソフトを開発支援 from ZDNet (13:49)

これはもう戦争ですか。いったいどのレベルに割り込んで監視して、それを海賊行為だと判断し、攻撃を実行するロジックを組むつもりだろう。正義クラッカー支援中って感じ? その正義は多分ごく少数にとっての正義だろう。

_ RFID機能無効化のスイッチ導入へ from ZDNet (13:49)

勝手にRFIDを無効化するクラックとかの対策をするのが大変そうだな。普及させるためには実装コストを下げなければならず、そうすると対策もある程度シンプルにならざるを得ず、そうするとある程度破られるリスクのある実装にならざるを得ず……と想像してしまうのだけど。RFIDに依存したシステムが動いてしまうと、RFIDが必要な状況においてRFIDが無効化されてしまうリスクというのは結構大きそうだしな。「非接触読みとりは無効化されるが、接触読みとりは可能」とか出来るかな? ってそれじゃーバーコード併用とかになっちゃうか。

_ 権限を伴わないCookieによるモード変更 (13:49)

ちょっとした思いつき。

Wikiみたいにリッチな機能を持つWebアプリケーションで、リッチな機能に対応するインターフェースリンクボタン)を常時表示しておくのはうざい。かといって、いちいち認証を通さないとリッチなインターフェースが表示されないのはうざいし、リッチなインターフェースとプアなインターフェースのページをそれぞれ別に作るのは面倒くさいし、切り替えを簡便化するために権限認証Cookieを使って表示内容を変化させるのはちょっといやだ(認証Cookieはできるだけ狭い範囲で有効になるようにしておきたい)。

というときに、まるで認証Cookieのように動作するけれども、実際には認証とは関係ない、表示切り替え専用のCookieを使って表示内容を制御するというアプローチは有効そうだ。Cookieで表示するスタイルシートを切り替えられるようにしているサイトがあるけれども、あれみたいな感じ。

ただ、そこで切り替えられる表示内容には、権限との相関関係が強いインターフェースが多く、まるで「表示モード切替=権限認証」のようにみえるだろう。具体的にいうと、モード切替で「一般ユーザーモード」を選択すると非常にシンプルなインターフェース(表示関連のリンク)しか表示されず、「編集者モード」を選択すると「編集」や「履歴」のような高度なインターフェース(リンク)も表示されるようになるイメージ。

しかし、内部的には権限認証と表示モード切替とは完全に切り離されている。だから、その表示モード切替のCookieが盗まれたところで、実際の権限認証とは無関係だ。一般ユーザーが「編集者モード」とか「管理者モード」を選択しても問題ない。ただ単に(一般ユーザーにとっては)不必要なインターフェースがたくさん表示されるだけだ。

いやまあなんてことない話なんだけど、Wikiでそういう風な実装をしている例ってあんまりないかなーと思って。Wikiに限らずWeb日記システムとかでも似たようなことが出来るよね。というかWebアプリケーション一般に適用できるか。要は、権限の実体とインターフェース(表示)は意味的には同じに思えるけれども、実は分離して管理してもいいよね、という話。Wikiのような、管理者・一般ユーザーの境目が不明確なシステムでは特に。

_ Visual Basicがすたれていく from ZDNet (13:49)

個人的にVB.NETの方がC#よりも好きなんで、VB.NETの利点・欠点を並べつつ宣伝しておこう。

VB.NETは、VBと名乗っていてVB文法とか昔のVB関数とかが使えるけれども、実際にはとてもちゃんとしたオブジェクト指向言語として作り直されている。もしも、VB.NET以前のオブジェクト指向サポート版VBを使ったことがあり、「あんな腐れオブジェクト指向もどき言語なんか使ってられるか!」と思っている人(過去の俺も含む)は、VB.NETはそれらとは別物であると認識し直して欲しい。とてもちゃんとしたオブジェクト指向言語に生まれ変わっている。C#がJavaを参考に新規に(後発で)作り直された洗練された言語であり、VB.NETはC#の記述力(言語仕様)をほぼそのままVB文法上に再現した言語だと考えると、その言語仕様の洗練度合いが想像できると思う。大元の言語仕様設計者はDelphi(Object Pascal)の人だし。

ただし、VB.NETはあくまでもC#が先にあって、それをがんばってVB文法に移植したものなので(多分)、C#と比べるとちょっとだけ劣る。C#で実現されている言語仕様のほとんどはそのまま使えるように移植されているんだけど、ごくわずかC#では使えるけれどもVB.NETでは使えない要素があったり、あるいは使えるけれども使い方が面倒くさかったり、あるいはC#ではちゃんと動くのにVB.NETではバグっている部分があったりする。でもまあそれは本当にごく一部でよほど運が悪くない限りはそういう要素に行き当たることはないだろう。

C#はJavaに似すぎている。そのため、Javaも使わなければならない人は、混同してしまう可能性がある。VB.NETの場合は言語仕様は似ているものの記述スタイルは全然違うので、混同してしまう可能性は少ない。というのは別の言い方をすれば、C#はJavaに似ているのでほとんど同じ知識を流用できる、ともなるけれども、俺の場合は違っていることの利点の方が大きい。でもまあ普通の人にとっては、似ていることの利点の方が大きいかな。

VB.NETはC#と比べると言語仕様的にコード量が少なく記述できるようになっている部分が多い。というのは、Visual Studio .NETの助けを借りることが前提なのだが、改行によって1命令が分離される言語スタイル+Visual Studioの入力支援によって、非常に多くの場合C#よりも少ない打鍵数でコードが入力できる。これには、VB.NETが大文字小文字を区別しない(ケースインセンシティブ)ことも貢献しているだろう。VB.NETでは、かなりアバウトにコードの一部を記述するだけで、その後に続くコードを自動補完できる。ただし、Visual Studioを使わずに入力した場合は、ブロック構造を中括弧で済むC#と、IF〜END IFのようなVB.NETでは結構差が出そうだ。Visual Studioを使えばその手のコードはすべて全自動で入力されるのだけど。

と並べてみたけれども、読み返してみると自分でもC#とVB.NETを比べて特にVB.NETを選択する意義があんまり感じられない文章だなー。俺の場合、もともとはC#を使いたかったんだけど、仕事でVB.NETを使わなければならなくなったんで、しょうがなくVB.NETを使い続けているうちに、C#と両刀遣いする気力がなくなった(VB.NETで書いてうまく動かなかったコードを、試しにC#で書き直して動作確認したりする程度)のに、後付けで理由をつけている感じだからなー。でも個人的には今後もVB.NETを使うつもり(私物としても買っちゃったし)なんで、廃れないで欲しいなー。


2005-05-07


2007-05-07

_ 1470.netのユーザーページで参照元が見られるようになりました

久しぶりの機能追加ですが、1470.netのユーザーページ(のパーマリンク)に対する参照元情報(いわゆるREFERER)の記録&閲覧機能を追加しました。といっても、MM/Memoの頃にはあった機能を今更ながらにリニューアル版にもつけただけなんですが。

ちなみに、1470.netではユーザーページは日付単位で管理しているので、参照元も日付ページ単位で管理されます。各日付ページの一番下にはその日付のページに対する参照元を()、ユーザーのトップページっ中段あたりには最近3日間の参照元()を表示します。

MM/Memoの頃とは違って、自分のページの参照元情報は自分だけ見られるというのではなく、誰でも見られるようになっています。また、MM/Memoの頃は最近の参照元情報のみ見られるようになっていましたが、今回は集計不可が大きくならない限りは、古い参照元情報も残しておく(見られるようにしておく)つもりです。