S・ジョブズ：iPodオープン化は「ソロバンに合わない」–株主総会で – CNET Japan

株主総会出席者の一部からAppleの市場シェアが縮小していることについて質問が出たが、Appleの経営陣は、同社がローエンドのデスクトップPC市場では戦わないとの決断を下したと説明。幹部の1人は、代わりに、利益率が高く40～50％のマーケットシェアを持つiPodに力を入れることにしたと語り、この判断を正当化した。

あー、とうとうこんなコメントがAppleの幹部から出ることになるとは。

Mac OS X 10.3 を(欲しいと思わないので)買ってない。 iLife のアップデートも、GarageBand もグッとくるものがない。 iPod Mini もアメリカで今の生活してる限りは欲しいと思わない。 と、最近 Apple が出してくる新製品が全然魅力的に思えない。 ハードウェアにしても先日、やっと新製品が出たと思ったら CPUのスピードアップやSuper Driveが付いたというモノで、これまた全然グッとこない。

オレが欲しいモノとAppleが出したいモノの方向性が少しずつ違ってきているのをうすうす感じていたが、こういう発言を見るとなんか寂しい。少し前までの Apple はこれまでのコンピュータの使い方が確実に便利になるような、どこかワクワクするような考えや、それを実現するモノを提供していたがもうこういったワクワクは期待できないのだろうか。

しかし、今年のはじめジョブズがMac の年と言った割に不気味なぐらい静かなのは気になる。WWDC あたりでMac OS X 10.4 を始めとしたものスゴい発表があるまでの準備段階なのだろうか。 そうだと期待してもう少し待ってみたいと思う。 がんばれ Apple。

Tweet

Check

Share on Tumblr

グーグルで路線や株価などが検索可能に – CNET Japan

グーグルは、Google.co.jpに特殊検索機能を追加した。今回追加された機能は、路線検索、辞書検索、株価検索、荷物検索、会社情報検索の5つ。

アメリカではしばらく前から提供されていた特殊検索が google.co.jp でも使えるようになった。 実際の検索結果を表示するまでには検索結果から1度クリックする必要があるが、なかなか便利な機能だ。 特に英辞郎の検索はこれまで alc.co.jp からしかできなかっただけにありがたい。

しかし、頭にキーワードをつけるのはちょっとメンドウ。 そんなときにも Google Deskbar を使うとちょっと便利になる(かも）。 以下の検索コードを Google Deskbar の “Customized Searches” に登録すると、Ctrl-Alt-G で Google Deskbar へフォーカスがいき、割り当てたショートカット(Ctrl-E など)を使うことで、クリップボードにあるテキストをそのまま検索対象にできます。 ブラウザで表示している文章から検索を始めたい場合に便利かも。

人によってはコマンドのように明示的にタイプする方がいいという人もいると思うけど、Google Deskbar の使い方のひとつとしてどうぞ。

路線検索
http://www.google.co.jp/search?q=%E4%B9%97%E3%82%8A%E6%8F%9B%E3%81%88+{1}&ie=utf-8&oe=utf-8

英和辞書検索
http://www.google.co.jp/search?q=%E8%8B%B1%E5%92%8C+{1}&ie=utf-8&oe=utf-8&hl=ja

和英辞書検索
http://www.google.co.jp/search?q=%E5%92%8C%E8%8B%B1+{1}&ie=UTF-8&oe=UTF-8&hl=ja

株価検索
http://www.google.co.jp/search?q=%E6%A0%AA%E4%BE%A1+{1}&ie=utf-8&oe=utf-8

会社情報検索
http://www.google.co.jp/search?q=%E4%BC%9A%E7%A4%BE%E6%83%85%E5%A0%B1+{1}&ie=utf-8&oe=utf-8

クロネコヤマト 荷物検索
http://www.google.co.jp/search?q=%E3%83%A4%E3%83%9E%E3%83%88+{1}&ie=utf-8&oe=utf-8

Tweet

Check

Share on Tumblr

Wired News: With a DVR, the Puck Stops Here

Hunter said a lot of teams in the National Hockey League have a video coach who watches the game in the back office and communicates with coaches using a headset. The Sharks are the only team to use the bench monitor, however.
(ハンターは NHL (全米プロホッケーリーグ) の多くのチームが裏で試合を見て、ヘッドセットを使ってコーチへ情報を伝えるビデオコーチという人を採用している。 しかし、シャークスは唯一のベンチモニタを採用しているチームだ と語った。)

ウォリアーズはプレイオフへ進出できず、寂しいオフシーズンを過ごしているが、地元のアイスホッケーチーム San Jose Sharks (サンホゼ シャークス) は現在プレイオフの準決勝を闘っている。

この活躍の原動力(なのか?)、チームがベンチモニターを利用していることが紹介されている。 カメラがサーバに繋がっていて、映像がサーバに蓄積され、ベンチにあるTablet PCを使ってリプレイとかすぐに見られるというモノだ。 かっこいいー。

そういえばNFL(全米のアメフトリーグ)ではヘッドコーチ(カントク)がごっついヘッドセットを付けているのが特徴的だ。 あれは高いところから全体の動きを見て相手の戦略を伝える人とのコミュニケーションのために使われているという話を聞いたこともある。 このベンチモニターもNFLから来たのかと思ったら、NFLでは電子機器を使ったものは禁止されているらしい。 プロ野球ではこういうの使うとバッテリー間のサインがバレちゃうから一切ダメなんだろうな。

アメフトより攻守の交代が激しいホッケーやバスケでは1プレイ1プレイの質が落ちる場合が多い。 こういったシステムを使って記録を残し、試合後選手たちにどこが良かったか、どこが悪かったか伝えると、選手たちも勉強になる。 実際、コンピュータに慣れた最近の選手にはこのシステムの評判がいいらしい。 ただ、くれぐれもやりすぎて選手をへこませないように…。

Tweet

Check

Share on Tumblr

JAM LOG : オープンソースエバンジェリストの盲点

Daring Fireballさんで、Linuxを中心とするオープンソースサイドとMSやAppleのクローズドソースサイドに関して興味深い考察が述べられていましたのでチェック。筆者のJohnさん、Linux(と一般的なオープンソースソフト)に対するかなり厳しい批評をしています。ちょっと長いですが、なかなか面白かったので一部要約して和訳してみました。

いやー、面白いやりとりだ。

かいつまんで説明すると、Linux やオープンソフトウェアの大家である Eric Raymond 氏がプリンタの設定につまづいたという体験をもとに、もっと良い GUI を書こうと Blog に書いた。 そしたら John Gruber氏が、そうじゃない。 よい GUI を書こうなんて姿勢ではダメだ。 始めに GUI は最初にあってもいいぐらい重要なモノでプログラマが片手間にやってもいいモノはできない。 これがLinux やオープンソースのソフトの問題だと指摘したというモノ。

ユーザインタフェースは一番最初にそのソフトウェアに触れる部分となるので重要なのはとても同意できる。 特に大規模なソフトウェアではそうだろう。 しかし、プログラマとしての自分の中には見た目より、まず動くモノを作りたくなる気持もわからなくはない。 デザインを重視しても、実際の動きに合わせて調整していかなればいけないのも事実だ。 UI、機能をスタートにすべきかはわからないが、プロセスとしては 試行錯誤を繰り返し、よりよいモノを目指すのが現実的なところだろう。

しかし、オープンソースコミュニティ は顔も合わせたことのない開発者が何十人、何百人も集まって作業をしているので、むやみに他人を振りまわせず、試行錯誤といったフットワークの軽い開発手法は合っていない。 そのため、どうしても最初にあるモノ、最大公約数的に「これでいいか」いうモノに落ちついてしまうことが多い。 これはより良いソフトウェアを作る上では問題だ。 まだ考えがまとまっていないが、オフショア開発に関して、何かモヤモヤした気分があるのは自分の仕事が取られるとかそういうのじゃなくて、良いソフトウェアを提供する観点から見るとフットワークの軽さという点で問題がある気がしているからだと思う。

上のやりとりが提起してくれた問題はいろんな要因が考えられると思うので、まだ解決策を言うことができないが、開発プロセスにおけるユーザインタフェース部分の開発手法に問題があることをはっきりさせてくれた。 自分も含め、デベロッパはこのまま黙っているつもりはない。 これをきっかけに少しでも良いものを作っていきたい。

Tweet

Check

Share on Tumblr

以前書いた “ベイジアンアルゴリズムは効くのか?” では、Thunderbird のスパムフィルタ機能が思ったように機能しなかったことと、オレが確率論そのものを胡散臭く思っていることから、ベイジアンアルゴリズムによるスパムのフィルタリングに対する疑問を書いたが、その後調べていくうちにいろいろわかってきたので紹介したいと思う。

まず、コメントで教えてもらったPOPFileというソフト。 自分でも使ってみたが、思った以上に機能して驚いた。確かに、スリ抜けるものもあるが、その数はThunderbird の比ではない。

管理画面で、メール中のどの単語がピックアップされ、どの確率で使われているか表示されるとよくわかる。 これが本当のベイジアンアルゴリム(オリジナルのアルゴリズムを改良したモノのようだ)の威力なのかと再認識させられた。 みんながスゴいというのは伊達じゃなかった。

では、なぜ Thunderbird のスパムフィルタが機能しなかったのか。

Tips：えむもじら

training.dat はジャンクメールコントロールの学習結果を格納しているファイルであり、プロファイルディレクトリにあります。

このサイトにはジャンクメールコントロールに使われる、training.dat というデータファイルを参照することができる perl スクリプトが置いてある。 これを使って、オレの情報を見てみたのが下のデータ。

pmin=0.000000 pmax=1.000000 bmin=0
nGood 33
nBad  309
total non-spam tokens 11204
total     spam tokens 28344
0   572 0.990 span
0   238 0.990 neomail
.
.
.

nGood (Spamじゃなかったメール数) が極端に少ない。 nBad (Spam だったメール数) にしてもこんなもんじゃない。 もうちょっと調べるために training.dat を新しく作り変えて、手持のSpamメールを送り直してみて確かめたところ Thunderbird (version 0.5)は、スパムマーク(ゴミ箱アイコン)をクリックして、マークを付けたり、外したときだけ、そのメールの情報を training.dat に記録しているようだ。

つまり、スパムフィルタが通した通常のメールや、一度憶えて、スパムだと認識したメールは training.dat に記録されない。 一方、POPFile は何らかの方法で、ほとんどのメールが次回以降のスパムチェックのために記録されていく。 このヘンの処理方法の違いが、 Thunderbird のスパムフィルタが正常に機能しない理由じゃないだろうか。

ベイジアンフィルタの論文には、

A Plan for Spam

ベイジアンフィルタがうまく動く鍵は、大きく綺麗なコーパスにある。 そういうコーパスはベイジアンフィルタの入力としても使えるだけでなく、 その他のフィルタにもテスト用として利用できる。

とあるように、判断情報は多ければ多いほどよいらしいので、Thunderbird のような方法ではなかなか賢くなっていかず、いつまでも誤認識してしまう。 自分が今持っているメール全てに一旦スパムマークを付けて、スパムじゃないメールはマークを外すという作業をすれば、ある程度は改善されると思うがあまりスマートじゃない。 Thunderbird/Mozilla チームはこのへんの問題を認識をしているのだろうか?

相変らず、なんでうまくいくんだろうという部分に疑問は残るが、ベイジアンアルゴリズムは、結構機能するという風に意見を改めたいと思う。
Thunderbird/Mozilla のスパムフィルタに関しては今後も動向を追っていきたい。

Continue reading

Tweet

Check

Share on Tumblr