CNET Japan に「
オペラ、創立10周年を記念してブラウザを無償提供」という記事があった。
Opera Software が創立10周年を記念して
通常1ライセンスあたり39ドルの登録コードを
無料で提供してくれる、という内容だった。
通常のメイン・ブラウザーをオペラにしていた私は、
ライセンスを購入せず広告を表示させたまま利用していた。
これは、絶好のチャンス、とばかりに、
この記事にある
パーティサイト にアクセスしてみた。
カリフォルニア時間の8月31日午後3時頃であった。
開いたページからライセンスをくれるというページへのリンクを辿ると
E-mailアドレスを登録する画面になった。
素直に自分のE-mailアドレスをサブミットすると
Operating System 毎の Registration Code の一覧になった。
早速、Windowsの欄の登録コードをカット&ペーストで
今使っているオペラのライセンス登録画面に書き込んでみた。
すると、確かに、今まで表示されていた画面右上の広告が消えた。
その直後にもう一度 オペラのパーティーサイト のページにアクセスしてみたが
「Internal Server Error」というエラーが表示されて元の画面にはアクセスできなかった。
20分ほどして、もう一度アクセスしてみた。
エラーはでなかったが、先ほどまであった内容にとって代わって、
アフィリエイト・プログラムに参加してくれたら
無償ライセンスをくれる、という内容に変更されていた。
この無償サービスは8月31日いっぱいということだったので、
私がアクセスしたのが、ちょうどノルウェーでの8月31日の終わりだったのではなかろうか。
このことから、私がもらったライセンスは、
もしかしたらこの無償サービスの最後のライセンスだったかもしれない、
と思ってしまった。
事の真偽はわからないが、最後の数人であったことは間違いない。
Opera Software 様、ありがとうございました。
ライセンスをいただきました Opera8 は、大切に利用させていただきます。
カテゴリー:
Browser
18:15
| コメント (0)
| トラックバック (0)
前回のエントリー「
Ethereal」まで、ActivePortsやら
この問題の原因究明のためのいろいろなツールを紹介してきた。
これは、実際に原因究明をする目的で私自身が調査した結果を
ここに書かせて頂いている。
では、この問題、最終的にはどうなったかと言うと
結局は問題ノートPCにインストールされていた
Symantec AntiVirus Corporate Edition の
Virus Definition File が 23日にアップデートされた。
それを基にウィルス・スキャンしたら、
W32.Esbot.C と Trojan Horse のウィルスが発見され駆除された。
その後、確認作業を行ってみたが問題は発生していないようだった。
ここで発見された
W32.Esbot.C
は、 Microsoft Windows プラグアンドプレイの
バッファオーバーフローの脆弱性を悪用しようするワームである。
この脆弱性については、「
マイクロソフトセキュリティ情報 MS05-039
」に詳細が説明されているし、
この脆弱性を突いたワームについて、
CNET Japan のニュース記事でも、
「
Windowsワーム大量発生--ハッカーグループ間の抗争が原因か
」や「
Windows 2000の脆弱性を突くワーム攻撃が多発--ABCニュースやCNNも被害に」
などに解説されている。
結果論だが、この問題に関しては、何もしないでウィルス定義ファイルが
アップデートされるのを待っていれば自動的に解決できた問題であった。
しかし、問題が発生してから5日たっての解決である。
これを早いとみるか遅いとみるかは、ユーザのPC依存度の問題でもあるが、
PCをミッション・クリティカルに使っている場合には5日間というは
致命傷となってしまう期間である。
カテゴリー:
通信
22:43
| コメント (0)
| トラックバック (0)
久しぶりにニュースレター編集会議が行われた。
お題は「PCのカッコいい・怪しい使い方」
編集会議参加者みんなで普段使っているPCの
クールな使い方をお披露目しあったりするというもの。
いろんなことについて議論をしたが、特にブラウザーについては、各々のこだわりがあるようである。
会議参加者の中では Firefox を使っている人が多かった。
さて、実際の編集会議の内容は、いづれニュースレターとして正式に発行されるであろうから、
ここでは触れないことにして、ニュースレターでは取り上げられない編集会議中の雑談について
書いておこう。このブログをお読みの方々もそちらの方に興味があると思う。
今回の編集会議には女性が2名参加されていたが、
何がキッカケだったかわからないが、
PCの話しから不思議にも「ブラジャー」の話しになってしまった。
それではということで、今流行りの ヌーブラ(Nu Bra) について女性軍に尋ねてみると、
それを機会により一層話が盛り上がってしまった。
あまり、こういう話題は恥ずかしいので自分のブログでは書きたくないな、と思っていたが
参加女性のお一人から、「明日の『シリコンバレー24時』 が楽しみだな」みたいに
この「ブラジャー」ネタをこのブログに書くリクエストというか半強制というか、
のコメントを頂いてしまったので結局こうやって書いてしまった。
それから、編集長でもあり建築エキスパーでもある茂山さんへの
家に関する質問が飛び出した。
家を買うべきか、賃貸を続けるべきか、迷っている人にとっては
関心が高い問題である。
また、今、日本で問題視されているアスベストや鉛について、
アメリカでの状況についても質問が出た。
茂山さんによると、アメリカでも確かに約30年前までに建てられた家には
アスベストや鉛が利用されているが、古い家でも
それらが飛び散らない状況であれば問題ないとのことであった。
ということで、久々の編集会議も無事終わったので
近いうち、久々のJTPAニュースレターが発行されると思う。
皆さんお楽しみに。
カテゴリー:
JTPA
23:06
| コメント (0)
| トラックバック (1)
SJVENのボランティア・スタッフ・ミーティングの一環として、
8月ということで BBQパーティーを行った。
私にとっては、先週のJBCの「
NPO化記念、夏のBBQ大会」
に引き続き、日曜日が2週連続のBBQパーティーとなってしまった。
プールサイドBBQということで子供連れのご家族が何組かいらっしゃり、
子供達はプールで泳ぎーの、大人達は日陰に座り込んで
飲みーの、食べたりーの、でゆっくりくつろぎながらいろいろと
話し込んでいた、といった感じ。
今日もシリコンバレーは日差しが強く、日陰があったから助かった。
解散後、サンフランシスコからいらしていた女性の方が
足がないということで、
カルトレイン(Caltrain: サンフランシスコ・サンノゼ間を結ぶ電車)の
Lawrence駅まで私がお送りすることになった。
次のカルトレインの時間まで少しあったので、
シリコンバレーをご案内することになった。
アメリカに来て1年ほどの彼女は、
ずっとサンフランシスコにお住まいなので、
サンノゼの日系スーパーマーケットのミツワとか、
その隣の紀伊国屋ブックストアに行ったことがないということだった。
それでは、ということでサンノゼ地区にお住まいの方にはおなじみの
例のサラトガ沿いのモールへと向かった。
紀伊国屋の中をご案内しながら、いろいろお話しさせていただくと、
彼女は相当数のビジネス書や自己啓発書を読みこなしていることが判明した。
私もその手の本は結構読んでいる方だと思うが、おそらく彼女には負けてしまうだろう。
さすがSVJENのボランティアスタッフに志願されるだけのことはある。
その後、紀伊国屋店内で、いろいろなビジネス書を手にとりながら
「この本を読んだことがある」とか「この本のこの辺にはこんなことが書かれている」とか
「この人の書いた本は、こういう論調が多い」とか。
二人でビジネス書談義となってしまった。
なかなかこういうお話しができる相手と紀伊国屋に一緒に来たことがなかったので
短い時間ではあったが非常に楽しかった。
紀伊国屋からカルトレインの駅までの車の中では、
私のビジネスについてまで話しが及んだが、
彼女からいろいろと鋭いご指摘を多々いただいた。
さすがに良くお勉強されているだけあり 考え方が深い。
短い時間ではあったが、いろいろとお話しさせていただいた
彼女に対しお礼を申し上げたい。
また、そんな頑張り屋さんの彼女の努力が報われんことをただただ祈るばかりである。
カテゴリー:
SVJEN
22:48
| コメント (2)
| トラックバック (0)
前回のエントリー「
ポートを開いているヤツ(プロセス)は誰だ?」で、
ActivePorts だけでは、
セッションを張ろうとしている場合には、
そのリモート側のIPアドレスとポート番号を確認できないことについて書いた。
これができるのが、いわゆるパケットキャプチャー(capture)ソフト または
パケットスニファー(Sniffer)ソフトといわれるものである。
通信パケットのキャプチャーソフトにはいくつかあるが、
その代表的なものの一つが
Ethereal
である。
Windows版をはじめ、
FeeBSD や Mac OS X 等のBSD系、
各種Linuxディストリビューション、Solaris、AIX、HP-UX 等々、
ありとあらゆるプラットフォームに対応している。
Windows版のEtherealでは、
WinPcap
と呼ばれる パケット・ライブラリーが必要になるが、
最新のEtherealのインストーラーにはそれが含まれている。
Etherealの詳しい使い方がここでは触れないが、
このソフトの基本的は考え方としては、通信パケットを無条件にキャプチャーしておいて、
表示する際にフィルタして必要なパケットだけを見やすく表示しよう、
という感じ。
だから、キャプチャーパケットのフィルタ設定も指定できなくはないがあまり細かくはない。
一方、表示する際の Display Filter については、非常に細かな条件を設定できる。
このEtherealを使えば、ActivePorts の足りない部分を補うことができる。
つまり、今回の例であれば、TCPのディストネーション・ポート番号 445 のパケットのみを
表示するようにしておけば良いわけである。
ちなみに、パケットリアルタイムに表示させるためには、
Capture Options画面にある「Update list of packets real time」
オプションをオンにする必要がある。
ここで表示されたソース・ポート番号と同じ番号を ActivePorts 上で探せば
このパケットを送出したプロセスを突き止めることができる。
ここでは、Ethereal と ActivePorts という2つのツールを利用したが、
この2つの機能を統合したツールは存在しないのだろうか。
もし、ご存知の方がおられたら、コメントなりトラックバックなり
頂けたらありがたい。
カテゴリー:
通信
23:41
| コメント (0)
| トラックバック (0)
本日、大学間連絡会議がマウンティンビュー(Mountain View)で行われた。
参加者は10名。7月がお休みだったので、2ヶ月ぶりの開催となった。
今度の9月の定例会はサンフランシスコ領事館で山中総領事もご出席ということになっている。
これをいい機会として、この会としての在り方をしっかりと確立しておこうということで、
今回の会議で、会としての正式名称とか、会としてのポリシーについて決めることになった。
その結果、正式名称は「ベイエリア大学間連絡会議」、
アメリカで活動しており英語表記も必要な場合があるので
「Japanese University Network in Bay Area」という英語表記とすることに決定した。
本会のポリシーとしては、大学や日本学術振興会といったアカデミックな団体が主体ということもあり、
教育・研究を基本とし「人材育成、産学連携」をメインのテーマとする。
また、この会に参加している大学や地方自治体のそれぞれの活動に関する
情報交換・情報共有を行って相互協力を図ってゆく、というものである。
その他、従来どおりの各団体の活動報告や情報交換も行われた。
大阪大学ではサマープログラムとしてカリフォルニア大学サンタバーバラにて1ヶ月間の語学研修をされているそうである。
また、早稲田大学は多数の学生をアメリカを含めた世界各地に送りこんでいるいるという情報も交換された。
いろいろ情報を集めてみると日本の各大学も活発な活動を行っているようである。
ちなみに私もこの場を借りて、鹿児島大学のシリコンバレーオフィス開所式と
学生研修ツアーについてもご説明させていただいた。
カテゴリー:
JUNBA
19:03
| コメント (0)
| トラックバック (0)
先日のエントリーで、ウィルスに感染していると考えられるノートPC
について書いたが、
今回はその解析方法に関して調査した際のことを書いてみたい。
前回、ウィルスが感染していると思われるPCから
大量のパケットが発信されて、ルータがハングしてしまった、
と書いたが、その原因を突き止める必要がある。
AntiVirusでもウィルスが引っかからない状況において、
では、そのPCの中のどのプロセスが大量パケット発信を行っているか?
それをWindows既存のツールだけで知るのは難しい。
まず、IPコネクションに関しては、
netstatコマンド があるが、-a オプションを付けて実行すると、
現在のTCPのコネクション、それから、TCPとUDPのListen状態の
ポート番号が一覧できる。
但し、この一覧からはどのプロセスがそれを行っているのか特定することができない。
ちなみに、WindowsXPのnetstatコマンドには、-o オプションが追加されて、
プロセス番号が併記できるようになったので、
タスクマネージャーと組み合わせれば
そのプロセス番号からどのプロセスか判別できないことはない。
しかし、今回のノートPCのOSはWindows2000である。
このような場合に、IPのコネクション情報とプロセスの情報を同時に表示してくれる
ツールがある。それが「
ActivePorts」である。
このツールは、ポート情報と、そのプロセスの番号(PID)とプロセス名、その実行ファイルのパスまでもを
リアルタイムにウィンドウでモニターできる。
オプションでアップデート・スピードを設定できるし、ポーズすることもできる。
コンパクトではあるが強力なツールである。
但し、今回の場合、この ActivePorts だけでは全ては解決しない。
プロセスがコネクションを張りに行く際、
コネクションが確立するまではリッスン状態であり、
相手のIPアドレスやポート番号が表示されないのである。
これでは、接続か確立しなければ、相手先のポート番号445に
コネクションを試みているということを確認できない。
そのため、また別のツールが必要になるのだが
それについては後日のエントリーとさせていただく。
カテゴリー:
Windows
,
通信
23:17
| コメント (0)
| トラックバック (0)
今日はJTPA技術交流会の日であった。
最終的な出席者は7名で今回から新たに加わった方が1名おられた。
私が会議室に着いた時、既に常連のお二方が会話されていた。
話しに加えていただくと、そのうちのお一人は、
最近、Sun Microsystems の 川原英哉氏とお知り合いになり、
先日ご本人から直接 Looking Glass のデモを見せていただいたそうである。
うらやましい限りである。
ご存知ない方のために簡単に説明させていただくと、
川原英哉氏は「IT業界のイチロー」とも形容されている方で
新しい3次元デスクトップ・インターフェースを一人で開発され、
それを オープンソースプロジェクト「Project Looking Glass」
として、サン マイクロシステムズの一プロジェクトにまでしてしまった、
という方である。
詳しくは
「Project Looking Glass の全貌」
にこのプロジェクトについての川原英哉氏ご自身による解説があるのでそれを参照されたし。
その後、他の方々が集まってからでも、この Looking Glass や、
他の三次元プロジェクトについて議論した。
この辺に詳しいエンジニア(ちなみに言うとハンドル名「はなびし」さん)によると、
三次元映像一般の人間に与える影響についての研究では、
視覚とそれを認識している脳の中で、矛盾が生じているので、
長く見続けると、疲労を感じるのが問題だそうである。
確かに、実際には三次元でない二次元の画像を
脳の中では三次元として認識させようと、
ある意味「騙し」ているわけなのだから、
脳が矛盾を感じるのも当然なのかもしれない。
それから、JTPAでは現在RFIDに関するセミナーを企画しているので
このRFIDについての技術的な面や応用面について議論が及んだ。
このRFIDのセミナーに関しては、間もなく、JTPAの方から正式に告知されることになろう。
その他の話題としては、
- Googleのサーチ、メール、デスクトップ・サーチや、その他の使い方のノウハウについて
- リナックスのディストリビューションやバージョンについて
- ウィルス被害の一例とその復旧についてのケーススタディー(これは昨日のエントリー
の内容)
などであった。
カテゴリー:
JTPA
22:27
| コメント (0)
| トラックバック (0)
奇怪な現象が出ているのでチョット見て欲しいという相談を知り合いから受けた。
お話しを聞いてみると、
あるノートPCを会社のネットワークに接続してしばらくすると、
会社全体がインターネットにアクセスできなくなる、ということであった。
もう少し詳しく状況を説明すると、
この現象は先週末から起き始めた。
そのノートPCのOSはWindows2000。
PCがウィルスに感染した可能性が高いので、
Windows Update 行って OSも最新の状態にしたし、
インストールされている Symantec AntiVirus Corporate Edition
の Virus Definition File も最新にしてスキャンを掛けた。
しかし、この日曜日の21日現在、ウィルスを発見できなかったそうである。
会社で使われているルーターは SONICWALL。
このルーターがしばらくすると、完全にハングアップしてしまう。
ハングする直前のログを取り出してみると、
08/21/2005 15:38:09.544 The cache is full; 6144 open connections; some will be dropped 192.168.20.52, 4428, LAN 216.1.XXX.XXX, 445, WAN
こんは感じ。
このノートPCのユーザーの方も、ネットワークに繋がないと仕事にならないし、
かと言って、ネットに繋ぐと しばらくしてから、その方を含め会社の全員、
インターネットが使えなくなってしまう、というジレンマであった。
実は昨日、私も現場に呼び出されて行ってみると上記のような状況であったのだ。
おそらくウィルスかスパイウェアの仕業と思われるが、
AntiVirusでも引っかからなければ、それらを特定するのは非常に難しく
解決には時間がかかりそうであった。
さて、この局面で、私が行った 次の一手 をご紹介しておこう。
このジレンマを抜け出すためには、ノートPCを直そうとせず、
先ず、ルータがハングしないようにすること。
そうすれば、たとえPCの中にウィルスが居続けたとしても、
そのPCの持ち主の方も、他の社員の方々もインターネットでの仕事を続けられる。
では、なぜ、ルータはハングしたのか?
上記のログを解析してみると、「The cache is full」とか「open connections」
という記述がみつかる。それから、ポート番号 445 への接続であったことがわかる。
ちなみに、上記「192.168.20.52」というのが、その時点での問題ノートPCのIPアドレス。
以上のことから、
「問題ノートPCのウィルスが自己増殖するために、不特定のIPアドレスのポート445 に向かって、
大量のパケットを送信している。 ルータはNAT(Network Address Translation)を行うために、
そのパケット情報を一時的にメモリに保持しておかなければならないが、
そのパケットの数が多すぎてメモリがパンクしてしまっている。」
という仮説が立てられる。
では、上記仮説が正しかった仮定すると、どうしたら、この現象の発生をくい止めることができるのか。
要は簡単で、問題のパケットを受け取らなければよいだけの話し。
そこで、
「LAN側の不特定のIPアドレスから、WAN側の不特定のIPアドレスのポート番号445に対するTCPパケットを拒絶する」
という記述をSONICWALLのパケット・フィルターに追加した。
問題ノートPCのユーザーの方から聞いた話しでは、
その後、ルータはハングしなくなったそうである。
ただし、これはあくまでも暫定的な解決方法であり、
おそらく、問題ノートPCには何ならのウィルスが存在していると考えられる。
その後の展開については後日のエントリーとさせていただく。
カテゴリー:
通信
21:20
| コメント (0)
| トラックバック (0)
アイセックという団体の東京大学委員会の皆さんが
独自のシリコンバレーツアーということでJTPAにコンタクトされてきた。
そこでこの日、梅田さんのオフィスにてミーティングを持つことになっていた。
このミーティングには8名の学生の皆さんがいらっしゃり、
梅田さん、千賀さんに加え、私も同席させていただいた。
梅田さんのブログ「1986年生まれの大学一年生が来た」 でも書かれているように、
学生の皆さんは 19歳、20歳という若い方々で文系の方が多かった。
「日本にいて海外に目を向けている、しっかりした考えかたの若者」と言うのが
私の第一印象だった。
ミーティングでは、
アイセックという団体についての説明や、それぞれの自己紹介をしていただいた。
また、JTPA側の梅田さん、千賀さん、私の3人もそれぞれ
シリコンバレーに来た経緯やら現在の仕事について語った。
学生さんの中には女性が3名いらしたので、
特に千賀さんの経験談は参考になったようだった。
その後の質疑応答の際に、大学時代の経験についての質問があったので、
自分の経験を述べさせていただいた。
ただ、自分では、ついこないだの大学時代のことを話しているつもりなのに、
考えてみると、それは彼らが生まれる前の事なのである。
ある意味、ショック。
以前、私の母親が、私が東京オリンピックを知らない事に気づき、
実の母親ながら驚いていたのを覚えているが、
ちょうど同じような心境であったのであろう。
私がこういう活動に関わるようになったからかもしれないが、
最近、若い方々がシリコンバレーを訪れる機会が増えてきているように思う。
今後益々、若い方々に来硅していただきたものである。
カテゴリー:
JTPA
22:22
| コメント (0)
| トラックバック (0)
JBCによるバーベキュー大会がパロアルトの Mitchell Park で行われた。
日曜日の昼間と言うこともあり、ご家族連れも多数参加されていた。
このバーベキューの準備は JBC「料理部BBQ課」が担当となっているが、
実際のところは 赤間さんと田中さん。
準備されたメニューは、ビーフやチキンはもちろん、
焼き鳥、海老、アサリの醤油焼き、
焼きとうもろこし、焼き芋、そして焼きおにぎり までと多彩。
最後には、掛けうどん まで振舞われた。
また、余興として、ピニャータやスイカ割りとか
子供さんにも楽しめるイベントが用意されていた。
そして中でも注目は、赤間さんのギターと 小柳さんのトランペットの共演。
これはハッキリ言って すばらしかった。
演奏曲目は、懐かしいところで「宇宙戦艦ヤマト」、「太陽にほえろ」、「Stand by me」、
そして新しいところで「冬のソナタ」。
バーベキューにご参加の皆さんはもちろん、公園の周りの方々までが うっとりと聞き込んでいた。
夕方になって、皆さんボチボチ帰り始めたので、
日が落ちて暗くなる前にお片付けをしましょう、ということで
沢山の機材を車に積むところまでは、どうにか日暮れ前に終えることができた。
が、結局辺りが暗くなってからも延々と駐車場で話し込んでしまった。
長い長い、でも楽しい一日であった。
最後に、赤間さん、バーベキューの準備からギター演奏まで今日は本当にお疲れ様でした。
カテゴリー:
JBC/LSJ
23:46
| コメント (0)
| トラックバック (1)
渡辺千賀さんのブログで「キカイダー」の話題
が盛り上がっている。
はなびしさんからのコメントにもあったように、現在、
シリコンバレー・ベイエリアでも土曜の深夜に放送されている。
何を隠そう、この深夜の放送のキカイダーを私も毎週欠かさず見てたりする。
日本でのオリジナル版が放送されていた際にも見ていたのだが、
さすがに当時は幼かったので細部に関してはほとんど忘れていた。
しかし、この年になってから改めてみてみると、
予想以上によくできていて関心している。
現代と比較すると特撮の技術などの未熟さは隠せないが、
見るに耐えないことはなく、今の子供達にも十分通用するのではなかろうか。
幼い当時は考えも及ばなかったが、
当時の限られた技術、限られた予算、限られた時間で
よくこれだけの作品を作り上げたものだなと、
作る側の苦労を想像してしまうのは、年のせいか、それとエンジニア気質のせいか?
キカイダーとくれば、必ず対比されるのが「仮面ライダー」であろう。
そう言えば日本のこの手のヒーロー物は、仮面ライダーといい、キカイダーといい、
それから月光仮面といい、みんなオートバイに乗っている。
一方、アメリカのこの手のヒーロー「バットマン」は車に乗っている。
この辺が ホンダ・ヤマハ・スズキ・カワサキ と二輪車が強い日本と
GM、フォード、クライスラーのビッグ3に象徴される車社会アメリカの違いかなと
ふと思ってしまった。
キカイダーに出てくる悪の軍団が「ダーク」と呼ばれているが、
一方の仮面ライダーの方は、ご存知「ショッカー」。
「♪ せまるショッカー、地獄の軍団 ♪」と主題歌でも唄われているので
皆さんご存知のハズ。
このショッカーの怪物の多くは昆虫をモチーフにしており、
仮面ライダー自身が「コオロギ」を基にデザインされているらしい。
そして、この地獄の軍団の組織名称「ショッカー」も昆虫についている「ショッカク(触覚)」からモジられたと聞いたことがある。
そういえば、今、日本では、ショッカクならぬ「シカク(刺客)」というのが流行っているのでしょうか?
お後がよろしいようで。
カテゴリー:
昔話し
22:38
| コメント (1)
| トラックバック (0)
今日は、飛んできちゃいました。
スカイメリカとして、シリコンバレーでの新しいフライト・ツアーを
企画するため、テスト・フライトと言うことで飛んできてしまった。
もちろん私はライセンスも持っていないので、
パイロットさんに操縦していただいた。
このパイロットさんが実はスゴイ方でして、
いずれこのブログでもたっぷりとご紹介させていただきたい。
今日のフライトは サン・カルロス(San Carlos)空港から
セスナ172スカイホークSP (Cessna 172 Skyhauk SP)で離陸。
オラクル本社の真上を通過してから、101号線に沿って少し北上。
高度を上げて行くと右手下には
サンマテオ・ブリッジ(San Mateo Bridge)が見えてくる。
今日は、サンフランシスコ上空には雲がかかっている模様なので、
それを避けて 競馬場(Bay Meadows Race Course)上空から
左に旋回して92号線沿いに西に進路を取る。
するとサンフランシスコ空港(SFO)が右側の遠くに見える。
それからさらに左に旋回して280号線沿いに南に向かう。
280号線の西に横たわる貯水池、クリスタル・スプリングス の上空を飛ぶ。
しばらくそのままフライトすると、
左手にスタンフォード大学(Stanford University)の象徴、
フーバータワー(Hoover Tower)が確認できる。
フーバータワーを中心にバンクを掛けながらゆっくりと左旋回で回り込む。
パーム・ドライブ(Palm Drive)上空を横切る時、
キャンパスの真中であるオーバル(The Oval)の正面となる。
オーバルの周りは車では何度も走っているのに、
その中心にスタンフォードのSの字マークがあることをこのフライトで初めって知った。
オーバルの北側にはクラーク・センターがその独創的な形が上空からでもわかりやすい。
その後、101沿いに北上を続ける。
機体は既にサン・カルロス(San Carlos)空港滑走路の直線上に位置している。
高度を徐々に下げながら着陸態勢にはいる。
そして滑り込むように着陸。「ナイス・ランディング!」
今後、これを実際のツアーとして確立するためには、
どのようなコース取りが良いか等、沢山の検討事項があるが
それらを一つひとつクリアして何とか実現に漕ぎ着けたいと思う。
ツアーとして運営を開始した際は、このブログでも大々的に宣伝させていただくつもり。
ということで皆さん、乞うご期待。
カテゴリー:
スカイメリカ
22:35
| コメント (1)
| トラックバック (0)
私の肩書きの一つに、「鹿児島大学シリコンバレーオフィス特定研究員」というものがある、
と言うことを
以前のブログ でも書いた。
そして、それに関するお仕事のひとつに
「鹿児島大学シリコンバレー研修ツアー」
というものがある。
そのツアーとは、鹿児島大学の現役の学生さんに
シリコンバレーに来ていただき、
シリコンバレーの実際を 見て、聞いて、触れて、感じて
いただくのが目的である。
そのための 企業訪問、各種セミナー、懇親会 等を
手配し、そのご案内をするのが私の役目である。
既に、その第1回目の研修ツアーが2005年3月に開催されており、
お蔭様で各方面からご好評を得ることができた。
また、すでに第2回目をこの10月に開催することが決定しており、
その内容についても今後大急ぎで企画しなければならない。
この第2回目ツアーの企画・準備の過程を
第1回目のツアーを振り返りながら今後ブログ化してゆきたいと思う。
まず今回のエントリーでは、
第1回目の鹿児島大学シリコンバレーツアーに関する
主なブログやレポートを挙げてみよう。
カテゴリー:
鹿児島大学シリコンバレーツアー
23:03
| コメント (2)
| トラックバック (1)
私の知り合いのある団体が、
現在新しい企画を開発中ということで、
今日は無理を言ってそれに参加させていただいた。
まだ企画の段階なので、申し訳ないが
この団体の具体的な名称などは伏せさせていただく。
では、どんな企画かというと、無理やり題名をつけると
「日本語が話せるアメリカ人と語ろう会」
みたいな企画。
もちろん、どんなアメリカ人を、どこから、
どうやって連れてきて、何を語るか、
そして... と、ここら辺が
この企画のノウハウになってしまうので
詳細についてはまだ秘密。
自分の勉強にもなるし、一種の国際交流にもなる、
ということで、その団体の方に頼みこんだワケ。
そこに参加している日本人の役割は、
参加されるアメリカ人の方が持つ日本についての疑問に答えること。
今日、参加されたアメリカ人は
ほとんど完璧な日本語を話すので、
私は英語を一言も話す必要がなかったし、
教えるはずの我々日本人の方が
逆にいろいろ教わってしまった。
話しているうちに、
日本人であるはずの自分が如何に日本を知らないかがよくわかってくる。
ある意味、日本人にとっては怖い企画。
今後、この企画がどうなって行くかはまだわからないが、
将来的に面白い展開になるかもしれない。
その際は、また、このブログでレポートさせていただこう。
カテゴリー:
その他のシリコンバレー関連活動
21:46
| コメント (1)
| トラックバック (0)
「MSNメッセンジャーでビデオ会議ができません」
という様なご相談を過去にも2〜3軒受けたことがあるのだが、
実を言うと自分自身がMSNメッセンジャーをやったことがなかったので、
今まではお答えを控えていた。
最近、また同様のご質問を受けてしまった。
しかし、今後も同様のご質問を受けることもあるだろうし、
その際、何らかの解決策をご提案できた方がよいし、
良い機会なので、これに関して少し研究してみることにした。
例えば、今回の具体的なご質問の内容は、
ある種のサークル活動で、離れた地域の会員とテレビ会議を行うために、
ノートPCにMSNメッセンジャーをインストールして利用している。
各会員の家庭を持ち回りで回っているが、
あるご家庭からだとビデオ会議が問題なく行えるのに、
別のご家庭からはビデオの画像だけが映らなくなってしまう。
ちなみに、どちらのご家庭でもインターネット(Webのブラウズやメール)は
問題なく行えている。
という具合である。
この場合も原因はいろいろ考えられるし、
原因がひとつではなく複数の原因が重なっている場合も考えられる。
しかし、今回調査した結果、最も大きな原因の可能性は、
「使っているルータが UPnP(Universal Plug & Play) に
対応していない可能性」があること。
では、UPnP(Universal Plug & Play)とは何ぞや、とか、
UPnPとMSNメッセンジャーとはどんな関係なのか、とか、
今後詳細を調べて、少しずつブログにまとめてゆきたいと思う。
カテゴリー:
Windows
,
通信
20:33
| コメント (0)
| トラックバック (1)
前回の『
「PukiWiki/mbstring無しのPHPでの動作」による解決策(2)』
まで、PukiWiki におけるカレンダー機能プラグインのインストールについて
書いてきたが、おまけで、その際の失敗談をもう一つ。
このプラグインのインストールには、
cal.css という独自のスタイルシートを追加する必要があるのだが、
その方法の説明は
「PukiWikiのCSS(skin/default.ja.css)に追加(コピー&ペースト)して下さい 」
とあるので、それに従って skin/default.ja.css ファイルの最後に
cal.css の内容を追加したら何の問題もなかった。
このときは、手元の全てのブラウザ(IE6, Firefox, Opera7)でテストを行った。
また、そのインストール方法の説明には、
「@import url("cal.css"); っていう手も無いわけではありませんが... 」
とあるので、今後、他のプラグインをインストールした時の事も考えて、
追加したcal.cssの内容を「@import url("cal.css"); 」という一文に置き換えてみた。
そして再びテストしてみても問題なく動作していた。
但しこの時は手抜きテストで、たまたま開いていたIE6のみでテストを行っていた。
その後しばらくしてから、Firefox と Opera7 とでは、
うまく表示されないという現象に気づいた。
よくよく調べてみると、
「@import」
はCSSファイル内で記述する場所により動作が異なることが判明した。
IE6では、何処にあっても動作したが、
Firefox と Opera7 では、定義を始める前に「@import」行を書いておかないと
正常に読み込んでくれていないようだ。
規格の原典 にあたってみると、
The '@import' rule allows users to import style rules from other style sheets.
Any @import rules must precede all rule sets in a style sheet.
The '@import' keyword must be followed by the URI of the style sheet to include.
A string is also allowed; it will be interpreted as if it had url(...) around it.
のように、確かに、「他のスタイル・ルールより前に記述しておく必要がある」となっている。
Firefox と Opera7 は、厳密にこれに準拠しているのに対し、
一方IE6は、よく言えば寛大に、悪く言えばいい加減に、この規格に対応しているようだ。
今回は、上記のような経緯から、たまたまIEのみで確認してしまっていた。
こんなところにバグが潜む原因があるようだ。
私は、まだまだ、修行が足りないようである。
カテゴリー:
HTML/CSS
,
Wiki
22:33
| コメント (0)
| トラックバック (0)
前回は、「四間飛車とシリコンバレー」という題名なのに
野球の話しだけになってしまった。では今回こそは将棋のお話しをしよう。
私は将棋も好きで、小学生の頃からやっていたが、
その当時は単なる自己流で、あーでもない、こーでもない、と
自分なりに研究していた。
そんないい加減なやり方でも、小学生同士のゲームとしては、
周りの友達に負けることはなかった。
しかし中学になると、世の中そんなに甘くはなく、
どうしてもある友人には勝つことができなかった。
そこで、その友人にどうしてそんなに強いのかを尋ねてみると
彼は、定石を勉強していると教えてくれた。
お恥ずかしながら私はそれまで、将棋に定石というものがあることを知らなかった。
それから、定石本や詰め将棋本を読みあさりはじめた。
当時は中原誠名人の時代であったので、「中原誠のXXX」的な
本をよく買っては読んでいた。
最近の将棋に追随していないので、
今となっては的外れなのかもしれないが、
中学生当時の記憶を思い起こすと、
将棋の王道というかスタンダードと言えば「居飛車に矢倉囲い」で
あったと記憶している。
しかし、自分はどうも居飛車で指すのに抵抗があって
いつも振り飛車、それも「四間飛車に美濃囲い」
という戦法であった。
梅田さんの将棋ブログを読みながら、ふと考えてみると、
当時の 「四間飛車に美濃囲い」 という自分の「棋風」
(素人将棋に棋風なんていう格調高いものがあるとは言えないが)と
現在、シリコンバレーに住み着いている、という自分の「生き様」には
何か共通点があるのではないか、と感じてしまった。
つまり王道というかスタンダードというか、
そういうものから外れているという点、
もしくはそういうものに対して抵抗感がある点に関しては
中学生当時の戦法を今でもそのまま実践しているのかな、と
今の自分を顧みてしまった。
カテゴリー:
昔話し
21:26
| コメント (0)
| トラックバック (0)
梅田さんのブログを拝見していて、思い出した事、それから感じた事を書いてみたい。
梅田さんとは光栄にもJTPAの活動等でご一緒させて頂いている。
何を隠そう、私がJTPAの活動を始めたのも
梅田さんのCNETブログ
がきっかけであった。
梅田さんの先日のエントリー『
「野球への愛」に溢れた5作品でメジャーリーグをさらに楽しむ』 に、
梅田さんの野球との関わりについてが説明されていた。
それを読ませて頂いて、自分も小学生のころは学校から帰ると、
グローブとバットと軟式ボールという三種の神器を
自転車に積んで広場に一目散に集まっていたのを思い出した。
小学生高学年当時の私は、
試合用と練習用の2つグローブを使い分けていた。
試合用は決して高価ではないがチョット新しいグローブ。
そして練習用グローブは、小学生低学年のころから使っていて、
既に自分の手には小さくなってしまっているにも関わらず、
その上あえて親指と人差し指の間にある捕球部分をわざと外して、
もうグローブと呼ぶより手袋と言った感じのシロモノ。
それを使って「左手の手のひらでボールを捕る練習だ」と
馬鹿なことを言いながら練習していたものだった。
そんな私も中学に上がる際に、自分には野球は向いていないと悟って、
それ以来、野球をほとんどやらなくなってしまった。
その後、観戦する方にもあまり興味がなくなってしまい、
今ではアメリカに住んでいるにも関わらず、
大リーグのこともほとんど知らない有様だ。
梅田さんは将棋に関しても造詣が深くいらっしゃるが、
私にとって、こと将棋に関しても、この野球と同じような思い出がある。
今回のエントリーでは話しが四間飛車まで辿り着かなかったが、
それは次回とさせていただこう。
カテゴリー:
昔話し
20:21
| コメント (0)
| トラックバック (0)
アメリカに住んでおられる日本人の中には、
日本語版OSを搭載したPCを利用している方も多い。
サンノゼには日本からのPCの輸入業者のショップもあるくらいで、
日本から輸入された純粋な日本語OS、日本語キーボードのPCを利用されている方も多い。
さて、日本人であっても、アメリカに住んでいる方にとっては
日本語キーボードが使いにくいと感じ、
デスクトップPCのキーボードをアメリカのキーボートと交換する場合がよくある。
その場合、問題が起きることが多い。
日本語配列キーボードと英語配列キーボードとは
基本的にアルファベットは同じ配列なのだが、
特殊文字、例えば、
括弧 ( ) [ ] や コロン : 、@ や $ % 等の 配置が微妙に異なっている。
そして、これらのキー入力が正常にできなくなってしまう場合がある。
対応方法としては、マイクロソフトのサポートページに
「
日本語キーボードが英語キーボードとして認識されてしまった場合の対処方法」
や
「
101 英語キーとして認識される」
に説明がある。
但し、アメリカに住む日本人の場合は逆のパターンで、
「英語キーボードが日本語キーボードとして認識されてしまった場合」となる。
そのため説明文中の「101/102 英語キーボードまたは Microsoft Natural PS/2 キーボード」
と「日本語 PS/2 キーボード (106/109 キー Ctrl+英数)」とあるところを
入れ替えて読む必要がある。
私が遭遇した問題では、デバイス・マネージャではちゃんと
「101/102 英語キーボードまたはMicrosoft Natural PS/2 キーボード」
と表示されているのに、特殊キーからの入力が日本語配列キーボードから
入力されているようになっていた。
いろいろ試してみても解決できなかったので、改めて「ドライバーの更新」を行い、
PCをリブートしたら解決できた。
上記「
101 英語キーとして認識される」
には、
お使いの環境によっては、デバイス名の表示上、異なっているだけで、実際のキー入力は、日本語 106/109 配列で、正常に入力可能な場合もあります。
とあるが、これは裏を返せば、
「お使いの環境によっては、デバイス名の表示は正常ですが、実際のキー入力は、異常な場合もございます」とも解釈できる。
運悪く、私が遭遇した一件は、後者のタイプだったのであろう。
Windowsでは表示されているディバイス名称までも疑ってかからなければならないようだ。
カテゴリー:
Windows
21:31
| コメント (0)
| トラックバック (0)
ワイヤレスLANを利用する場合、暗号化をしなければ外部から不正アクセスされてしまう、
ということは既に皆さんお聞きになったことがあると思う。
WindowsXPでは初めから Wireless Zero Configuration という サービスで
ワイヤレスLANに対応しているが、そこで用いられている暗号化方式がWEPである。
WEPとは、通常 Wired Equivalent Privacy の頭文字だといわれているが、
マイクロソフトのサイトでは Wireless Encryption Protocol とも説明されている。
「Wired Equivalent Privacy」とは言うなれば「有線と同じくらい安全だよ」というような意味だが
実は結構安全性の問題が指摘されている。
そのため現在は、WEPより安全性が高いといわれる WPA(WiFi Protected Access)
が利用できるようになってきている。
しかし、全てのデバイスが対応している状況ではないので、しばらくはWEPを利用するのが
現実的であろう。
このWEPのデータ暗号化には、64ビットと128ビットという2つのレベルがある。
64ビットの場合、暗号化キーは40ビットで16進数(ヘキサ)で10桁、文字列(アスキー)で5文字となる。
一方、128ビットの場合、暗号化キーは104ビットで16進数(ヘキサ)で26桁、文字列(アスキー)で13文字となる。
さて、そこで今回の話題は、WindowsXPの 標準ユーティリティーである
Wireless Zero Configuration において、
WEPの暗号化キーを入力する際、16進数(ヘキサ)で入力するべきなのか、
文字列(アスキー)で入力するべきなのか、という疑問について。
では実際に試してみようということで、
アクセスポイントとして、Linksys(Cisco)のWRT54G を使って実験してみた。
WRT54GでWEPの設定をする際はパスフレーズから自動的に4つのキーを生成することができるが、
ここでは、その機能を使わず、キー1の欄に 16進数でキーを入力した。
実験を簡単にするために暗号化に64ビットを選択したので、
16進数で10桁となる「4142434445」を入力した。
なぜこの様なキーにしたかたというと、16進数の「41」が「A」に、「42」が「B」に対応する。
よって、「4142434445」は文字列に直すと「ABCDE」ということになるのである。
ではまず、WindowsXPにWEPキーとして「4142434445」を入力してから接続してみると
問題なく接続できた。
次に、WEPキーを「AAAAA」として試してみた。予想通り繋がらない。
これはWEPキーが食い違うと繋がらなくなることを確認するため。
最後に、WEPキーを「ABCDE」にして再度接続してみる。すると、何の問題もなく接続できた。
結論として、WindowsXPのWEPキー入力は、16進数(ヘキサ)、文字列(アスキー)のどちらでも構わない、
ということが判明した。WindowsXPのWEPキー入力部分には、
暗号化の64ビットと128ビットの選択がないが、これは入力されたキーの桁数から
判断しているようだ。ここに入るキーは、5桁、10桁、13桁、26桁のいづれかであり、
かつ、10桁、26桁の場合は、16進数である 0〜9,A〜F でなければならないことになっているようだ。
試しに、入力を4桁にしてみたり、10桁でも16進数でない文字を混ぜてみたりすると、
ネットワーク パスワードはネットワークの構成により、40ビットまたは 104ビットでなければなりません。
これは、ASCII文字で5または13文字、16進数では10または26文字で入力することになります。
というエラーメッセージが出てくる。
カテゴリー:
Windows
,
通信
21:53
| コメント (0)
| トラックバック (0)
JTPAのセミナー「300万画素に騙されるな、携帯電話カメラの裏話」
が行われた。
講師はゴードン笹森氏。
ゴードンさんはJTPA技術交流会にもいつも参加されている方。
そちらの関係から今回のセミナーが開催されるに至った。
セミナーの開催場所はゴードンさんがお勤めの
マイクロン テクノロジー (Micron Technology) 社。
サンノゼの空港から101を横切って少し北にいったところで、
お向かいが eBay の広い敷地となっている。
お隣には、ワイヤレス・ネットワーク機器で有名な
Proxim
の看板が見える。
入口から入ってみると、大手半導体会社だけあってセキュリティーがしっかりしている。
ゲストブックに署名後、各人にビジター用のICカードが渡され、
それを改札機のようなゲートにかざしてから入館しなければならない。
集まった参加者はスタッフまで含めて約20名といったところであった。
では注目のセミナーの内容はというと、
これが残念ながらブログでは詳しいことには触れることができない。
このセミナーは「ここで知りえた情報を口外しない」という条件(いわゆるNDA)の基に行われたセミナーなのである。
ということで、話しの流れだけ簡単に紹介させていただく。
講演はマイクロン社の概要紹介からはじまり、
このセミナーのメインテーマである CMOSイメージセンサー の概要や技術的特長について。
マーケティング的な面からCCDとCMOSイメージセンサーの市場動向と今後の予測。
それから、
プレス発表されたての新製品
のデモを見せていただいた。
参加者の中にはこの分野の専門家の方も多く、途中鋭い質問が飛び交っていた。
このブログで何らかのマル秘情報を楽しみにされていた読者の方を
ガッカリさせてしまったかもしれないが、
この手のセミナーには実際にご参加いただくしかない、
としか申し上げられない。
カテゴリー:
JTPA
23:33
| コメント (0)
| トラックバック (0)
ここ2〜3日、遅ればせながら iPad や iTunes をいじってみたわけだが、
この先どうなるのだろうか、とチョット考えさせられた。
新聞がウェブ上で見られるようになって久しいが、
それから電子ブックのようにテキスト・データがインターネットで販売されるようになり、
そして iTunes Music Store を始めとしてオーディオ・データも手軽にネットで購入できる
環境が整った。既に一部では始まっているようだが
映画やテレビ番組等のビデオ・データが現在の音楽と同様に
誰にでも簡単に入手できるようになるのも時間の問題であろう。
従来なら読者数が少なすぎて製本することが出来ずに葬り去られていた本、
一部のマニアの間でしか売れなかった今は絶版になってしまったレコードやCD、
観客動員がほとんどできなかったマニアックな映画、
昔幼かったころに見ていた懐かしのテレビ番組。
このように従来のメディアでは経済的にペイできなかった著作物が復活を遂げ、
ネットを通じて家に居ながらにして手に入る時代になってきた。
これは新たな市場の広がりとも言えるが、一方、
これらの媒体を扱ってきた中間業者、例えば、
新聞販売店、本屋、レコード(CD)ショップ、ビデオ販売やレンタル・ショップ 等は
今後どうしていけばよいのか。
時代の変化に応じて商売の形態も変化させて行けなければ、
今後ますます生き残りが難しくなってきている。
将来、家ではもちろん車の中でも街中でも、
テキスト・音楽・映画などなど、あらゆる情報(データ)が
いつでも手に入れられるようになったとして、
果たしてその次に来るものはいったい何なのだろうか。
iTunes をいじっていて、ふと、そんなことを考えてしまった。
カテゴリー:
Apple
22:29
| コメント (0)
| トラックバック (0)
過去2回のエントリーで iTunes や iTunes Music Store での
曲の購入についてなど書いてきたが、今回は iPod 自身について。
実は私自身は今まで iPod に触ったことがなかったが、
使い方を教えて欲しいという知り合いの方から iPod shuffle お借りした。
iPod shuffleを エンジニア的な見地から眺めてみると、
スイッチといい、ボタンといい、LEDといい
数少ないインターフェースで、筐体の色も真っ白と
シンプルなデザインにまとめ上げている。
アップルらしい製品だと感じた。
電源に関しても電池を入れたりするのではなく、
USBからの電力を内蔵のバッテリーで充電して利用することになっている。
筐体にもネジ一本なく、モールドで固めてあるので簡単に解体できそうにない。
ということは、内部に密閉されたバッテリーの充放電を繰り返すことによる劣化が
この iPod shuffle の寿命となるのであろう。
早速 iTunes が入っているPCのUSBポートに、iPod shuffleを差し込んでみる。
デバイス・ドライバーを追加でインストールする必要はなかったが、
シリアル番号を入力する必要があった。
完全に新たなディバイスとしての認識が終わると
iTunes の左側に iPod アイコンが表示される。
iPod shuffleに曲をダウンロードする方法はいたって簡単で、
ライブラリ・フォルダを開いて移したい曲をiPodアイコンに向かって
ドラッグ&ドロップするだけ。
手持ちのオリジナルCDの曲も iTunes経由でiPodに入れることができる。
PCのCD(DVD)ドライブにミュージックCDを入れると
iTunesが自動的にそのCDを認識して画面左側にアイコンが出てきて
右側にその曲目が表示される。
CDの曲をiPodに移す場合、CDから直接ドラッグ&ドロップすることはできない。
この場合は、CDの曲を一度ライブラリ・フォルダにインポートし、
そのライブラリ・フォルダからをiPodに移す必要がある。
CDからライブラリ・フォルダに移す場合も、データの形式を
AAC(Advanced Audio Coding)フォーマットに変換しているので
少し時間がかかる。
ただし、コピーコントロールCDからiTunesへ曲をインポートすることはできないようだ。
カテゴリー:
Apple
23:49
| コメント (0)
| トラックバック (0)
前回のブログ
で、iTunes Music Store の曲をブラウズすることができたので、
早速その曲を買ってみよう。
前回のブログで書いたとおり、
曲を表示させると、その行の最も右側に[曲を購入]ボタンがある。
それをクリックするとサンインインの画面になる。
ここで初めての場合は、新規アカウントの作成をすることになる。
さて、ここで問題。
このページの標題「日本のクレジットカード情報、住所を記入してください」となっており、
住所などの情報入力欄も全て日本の形式になっている。
標題の下に小さく「クレジットカードの請求先ご住所が日本でない場合は、こちらをクリックしてください」
とあり、矢印ボタンがあるので、それでは、と思い、このボタンをクリックする。
「国を選択してください」というページになるので、「米国」を選んでから
[国を変更する]ボタンをクリックしてみる。すると、
なんと英語のミュージックストア・トップページになってしまい、
今まで入力してきた新規アカウントの作成フォームには戻ることはできなくなってしまった。
これは一種の輸出規制で、日本に住所がない人には、日本の iTunes Music Store の曲は売らない、
ということなのかもしれない。
今回のこの購入は、使い方を教えて欲しいと依頼された私の知り合いの方と一緒にやってみたのだが、
その方は、しょうがないので日本で作った(日本の住所が登録されている)クレジットカードの情報を入力された。
すると何の問題もなく、選んだ曲がダウンロードできて、
画面左側の「ライブラリ」フォルダにデータが保存された。
今回は、日本のクレジットカードを使うことによって日本の曲を購入できたが、
さて、登録住所がアメリカになっているクレジットカードで、日本の曲を購入する
というのは可能なのだろうか?
ご存知の方がおられたら、このブログにコメントでもいただきたい。
カテゴリー:
Apple
21:24
| コメント (0)
| トラックバック (0)
最近、何人かの知り合いの方々から、iPod shuffle や iTunes の使い方を教えて欲しいとか、
日本の曲のダウンロード方法を教えて欲しい、と頼まれることがあった。
人に教えるためには自分でも使ってみなければ、ということでいろいろ試してみたので、
今日はその話し。
このブログをお読みの皆さんなら、今更でしょうが用語を整理しておこう。
Apple社のポータブル・デジタル・ミュージック・プレーヤーの総称が iPod 。
そしてそれは、iPod、iPod mini、iPod shuffle と大きく3種類に分かれいる。
(iPod U2 はSpecial Editionということでここでは除外)
それからMacやPCの上でオーディオコンテンツを扱うソフトウェアの名称が iTunes。
依存関係としては iPod を使うには iTunes が必要だが、iTunes を使うにあたって、別に iPod を持っている必要はない。
また、アップル社が最近日本でも始めたミュージックストア iTunes Music Store から曲を購入するためには iTunes が必要となるある。
では、実際に iTunes のインストールから試してみる。
実験機は PCで OS は Windows 2000。
iTunesのダウンロードはアップルの
このページ
から無料でできる。現在の最新バージョンは4.9らしい。
対応OSは、Windows 2000またはXP と Mac OS X v10.2.8以降となっている。
Windows版をダウンロードしてみたが、ファイル名が iTunesSetup.exe、
大きさが 22MB程であった。早速インストールしてみたが、全てディフォルトのままで
OKボタンをクリックしてゆくだけで何の問題もなくインストールが完了した。
再起動後、iTunes を起動してみる。いくつかの設定の問い合わせに
全てディフォルトで答えていくと、ミュージックストアに自動的に接続した。
表示された内容が USAのページだったので、
画面下の Choose Store: から Japan を選択してみる。
すると、日本の iTunes Music Store の画面になった。
トップページには「新作アルバム」だの「Today's トップソング」だのと、
いろいろなリンクがあるが、ちょっとなつかしの曲などをさがすのであれば、
「音楽をブラウズ」がいい気がする。
画面右上の目のような形のブラウズボタンをクリックすればよい。
メニューからなら、[編集]-[ブラウザを表示] を選択、
キーボード・ショートカットで Ctrl+B でもよい。
画面中央が3つに分かれて、左から ジャンル、アーティスト、アルバムというペインになっている。
最も左のペインには J-Pop を始め、35のジャンルから選択できる。
ジャンルを選べば、次にアーティスト、それからそのアーティストのアルバムを選べば、
そのアルバムに入っている曲名が画面下の欄に出てくる。
この曲を選択して、ダブルクリックか、または、プレイボタンをクリックすると、
その曲の30秒間の視聴ができる。
30秒間、視聴してみるだけでも結構楽しめるものである。
これを次から次へと繰り返せば、あなたもきっと
「ドレミファ・ドン」イントロ当てクイズ の王者になれる。
続きは次回のブログで。
カテゴリー:
Apple
23:15
| コメント (0)
| トラックバック (0)
前回の『
「PukiWiki/mbstring無しのPHPでの動作」による解決策(1)』の続き。
「
mbstring無しのPHPでの動作」に紹介してある解決策に関して、
プラグイン cal.inc.php の作者が「ここで書かれている方法では動きません」と
回答しているのはなぜなのか、という問題。
結論から言ってしまうと、
この解決方法で使用されている mbstring.php はサブセットであり、
mbstringモジュールが提供している関数の全てに対応していないから。
例えば、 mb_convert_kana() という関数は mbstring.php には実装されていない。
そのため、「mbstring無しのPHPでの動作」の策を講じても問題解決にはならない、ということである。
しかし、ここでの私の目標は mbstringモジュールの完全互換を達成することではなく、
cal プラグインがとりあえず走ってくれればよいだけである。
そこで何とかならないかやってみた。
まず、calプラグインでどれくらいmbstringモジュールの関数を使っているか調べてみる。
mbstringモジュールの関数は必ず「mb_」から始まっているので、pluginディレクトリから
%grep -n mb_ cal*
の様に grepコマンドで、ファイル名が「cal」から始まるファイルの中で、
「mb_」から始まる語句を検出し、結果に行番号をつけて表示する、
という検索を掛けてみる。
その結果、使われている関数は、
mb_strpos(), mb_substr(),mb_convert_encoding() そして mb_convert_kana() の
4つであることがわかった。
このうち、mbstring.php に実装されていないのは、
mb_strpos() と mb_convert_kana() の2つである。
実際に実行してみると、問題となるが mb_convert_kana() の方だけであるようだ。
そこで mbstring.php ファイルの最後に
// mb_convert_kana -- カナを("全角かな"、"半角かな"等に)変換する
function mb_convert_kana($str, $to_encoding, $from_encoding = '')
{
return $str; // 注: 何も変換しない
}
というように、mb_convert_kana() を実際は何も変換しない関数として追加した。
もぐらたたき的な対策ではあるが、これにより現在のところ大きな問題もなく cal.inc.phpプラグインが動作している。
カテゴリー:
Wiki
20:18
| コメント (1)
| トラックバック (0)
前回の「
日米間のインターネット通信速度(1)」からの続きで、
渡辺千賀さんのブログ「
教えてPlease:日米間のインターネットの速さ」
に対する私なりの回答を考えてみた。
前回のエントリー のとおり、日米間での信号の往復に 最低 10分の1秒 (100ms) かかると言うことは、物理的な限界だと言える。
そうすると、その場合の通信速度はというと、
「
教えてPlease:日米間のインターネットの速さ」の
かめぞう
さんがコメントでおっしゃられている
普通はファイル転送にメールやFTP等のTCPを使用すると思いますが、
遅延の大きい回線での帯域は回線の太さよりも遅延時間(RTT, round trip time)が支配的になります。
TCPではwindow sizeというパラメータで決められたデータ量を送信する毎に
ACKパケットを送受信して通信の信頼性を向上させていますが、
逆にACKパケットの送受信が完了するまでは次のデータを送信できないためです。
Windows XPのwindow sizeのデフォルト値(16KB)と、日本(川崎,プロバイダまでは100M接続)〜米国(以前いたStanfordの研究室)間の
ping応答時間(124ms)を用いて計算すると、下式の通り約1Mbpsとなります。
16KB/124ms×8bit=1.03Mbps
のとおりだと思う。
これによると、通常のWindowsを使用している限り、TCP/IPでは、
約1Mbps が上限となってしまう、ということだ。
では果たして、それ以上のスピードの回線を導入しても無駄になってしまうのだろうか?
ここで気をつけなればならないのは、上記の「日米間は約1Mbps が上限」というのは
1セッションあたりということだ。
ソフトによっては、1つのソフトで同時に複数のセッションを張ることもあるし、
その様なソフトを1台のPC上でいくつも同時に走らせることもあり得る。
かつ、そういう人(PC)がそのオフィスに何人(何台)か、いるかもしれない。
結局、導入する回線容量を考える際は、同時に何セッションが必要になりそうか、
ということを考慮しなければいけない思う。
カテゴリー:
通信
20:52
| コメント (1)
| トラックバック (1)
渡辺千賀さんのブログに「
教えてPlease:日米間のインターネットの速さ」
というエントリーがあったので、それについて私なりに少し考えてみようと思う。
日米間のインターネットの速さを計るのために、まず、
AboveNet Japan のネットワーク情報ページ
にある Trace Route のサービスを使ってみよう。
これで、日本にあるアバヴネットのサーバーから、
アメリカにある JTPA(jtpa.org)のサーバー間の
伝送ルートと時間を測定してみる。
結果は
Traceroute Output
FROM www.jp.above.net TO jtpa.org.
traceroute to jtpa.org (209.68.48.200), 64 hops max, 44 byte packets
1 mgmt1-tk1-servers.abovenet.ad.jp (211.13.224.2) 0.709 ms 0.690 ms 0.636 ms (0% loss)
2 211.13.234.18.available (211.13.234.18) 1.112 ms 0.940 ms 1.048 ms (0% loss)
3 so-3-1-0.mpr1.nrt3.jp.above.net (208.184.233.197) 1.080 ms 1.072 ms 1.058 ms (0% loss)
4 so-6-0-1.mpr3.sjc2.us.above.net (64.125.30.10) 112.848 ms 99.830 ms 112.851 ms (0% loss)
5 so-3-0-0.mpr2.sjc7.us.above.net (64.125.30.173) 99.678 ms 99.671 ms 100.374 ms (0% loss)
6 mfn-oc12.sjc.gblx.net (64.125.12.86) 99.686 ms 99.741 ms 99.716 ms (0% loss)
7 so0-0-0-622M.ar2.CLE1.gblx.net (67.17.68.122) 171.150 ms 171.040 ms 171.090 ms (0% loss)
8 Pair-Networks.so-2-1-0.ar2.cle1.gblx.net (64.214.174.178) 170.330 ms 170.436 ms 170.344 ms (0% loss)
9 192.168.1.191 (192.168.1.191) 179.554 ms 170.178 ms 170.027 ms (0% loss)
10 jtpa.org (209.68.48.200) 169.821 ms 169.985 ms 169.937 ms (0% loss)
ここで注目していただきたいのは、3行目と4行目。
3行目のルータのドメイン名は「nrt3.jp.above.net」となっており、
4行目は「sjc2.us.above.net」となっている。
これで、3行目のルータは日本の千葉県成田(NRTって、成田空港の空港コード)近辺にあって、
そこから海底ケーブルで太平洋を渡って、アメリカのカリフォルニア州サンノゼ(SJCって、San Joseの空港コード)
近辺の4行目のルータに転送されたと憶測される。
ではその間の時間について。
3行目に、「1.080 ms 1.072 ms 1.058 ms」とあるのは
おそらく東京にあると思われるアバヴネットのサーバーから、
千葉県成田のルータとの信号の往復時間を3回測定した結果。
平均して 1.070ms となる。
同様に、4行目に「112.848 ms 99.830 ms 112.851 ms」とあるのは、
アバヴネットのサーバーからサンノゼのルータとの往復時間。
平均して 108.510ms となる。
この結果から判ることは、日米間の最も近いルーター間でも、
信号が一往復するのに、約 100ms、つまり10分の1 秒 かかっているということだ。
さらにもう少しだけこれについて考えてみたい。
光や電気の伝わる速さは1秒間におよそ30万Kmと言われている。
それから、日本とアメリカの間の距離は、おおよそ8千キロと言われているが、
海底ケーブルは、おそらく、ハワイ経由であろうし、
海の中でも海溝を避けたりと最短距離のコースで敷設できず、
グニャグニャ曲がっていることであろうから、
ここではザックリ全長1万5千キロと考えてみよう。
ということは、往復では3万キロとなる。
この3万Kmとは、ちょうど1秒間に光が伝わる距離の 10分の1 なのである。
つまり、日米間での信号の往復に 10分の1秒 (100ms) かかると言うことは、
実は物理的な限界だったといえる。
では、千賀さんのご質問への回答を、と思ったら長くなりそうなので
次回への続きとさせていただこう。
カテゴリー:
通信
21:42
| コメント (0)
| トラックバック (1)
今日は、ある方にご紹介してきただき T氏(お名前を公表することの許可をいただいていないのでイニシャルにしておく)
のオフィスをご訪問させていただいた。
いろいろお話しさせて頂いていると、なんとT氏はマルチプラン(Multiplan) を開発された張本人であることがわかった。
開発されたプロトタイプをビル・ゲーツにも実際に会ってプレゼンされたそうである。
そしてそれがマルチプランとしてマイクロソフトからの発売に至ったということである。
Windows世代の若い方々はご存知ないかもしれないのでちょっと解説させていただくと、
マルチプランとは、PCのOSがMS-DOSの時代、
マイクロソフトからリリースされていた表計算ソフトウェアのベストセラーであり、
現在のエクセル(Excel)の前身ともいえるものである。
また、T氏は 創業間もない サン・マイクロシステムズ(Sun Microsystems, Inc.)の
スコット マクネリー(Scott McNealy)氏らからもお誘いを受けていたそうである。
その後、シリコンバレーを代表する大手ソフトウェア会社に入り、
その会社の日本支社の設立等にもご尽力されたそうである。
正に我々にとっては「シリコンバレーの大先輩」といったところで、
日本人でもこの様な経歴の方がいらっしゃたのかと、つくづく感心した次第である。
今日は、T氏とお会いできて非常に有意義であったとともに、
シリコンバレーに住んでいて本当に良かったと実感できた一日であった。
カテゴリー:
シリコンバレー
22:23
| コメント (0)
| トラックバック (0)
この日の夕方、SVJEN関連のミーティングが
Global Catalyst Partners の会議室であった。
SVJENをはじめJTPAでもセミナー等でよく利用される場所なのでご存知の方も多いと思う。
この様な場所をいつも無償で提供していただけるとは、本当にありがたいことである。
Global Catalyst Partnersのオフィスは Redwood City の 101号線沿いなので、
サンノゼ方面からは101を北上して、Redwood Shores Pkwy をexitするのが
最も簡単なルートである。
ところが、夕方、このコースを走ると結構混むことが多い。
特に私の場合、85号線から101に乗る必要があるので、このマージ(合流点)は非常に混む。
そこで今日は少し遠回りになるが、別の道をチャレンジしてみた。
コースとしては 280号線をずーっと北上してから92号を東へ、それから101を逆に南下して Marine Pkwy を降りて東へちょっと。
オラクルの本社ビルを左手に見ながら、ちょうどその正面からTwin Dolphine Dr. を南へ、というルートである。
距離的には確かに遠くなるが、時間的には混まない分、短くなるようだ。
帰りは、もう混まない時間なので距離の短い101南下から85号線のルートで帰ってきた。
カテゴリー:
SVJEN
23:12
| コメント (0)
| トラックバック (0)