グローバル化と文化の侵略の違い

よく見ると2010年の記事だったのですが、たまたま見かけて思う所があったので書きます。

chikirinさんのブログにグローバル化に関する記事があって、以下の様に書かれています。

...

グローバリゼーションとは、日本人に英語を習わせることではない。それは、世界の人を受け入れること。世界の多様性を受け入れることを言うのだ。

...

「多様な価値観、自分達とは異なる思考や経験をもつ人を、意思決定や組織運営を共に行う仲間として迎え入れること」

...

少しこれらの事は置いておいて、自分の思うグローバル化を想像してみてください。日本におけるグローバル化と海外におけるグローバル化を想像して見てください。

前者は、恐らく日本のオフィスに日本人に混じって白人がいて、皆が英語で話している感じのものを想像しませんでしたか?後者については、白人に混じって日本人がいて、皆が英語で話している感じのものを想像しませんでしたか?もしそれらに差があるならば、まずあなたが定義しているグローバル化は、グローバル化ではなく文化の侵略です。しかも、文化の侵略をする方ではなく、される方です。文化の侵略をされる事を、グローバル化と定義しています。

先程のchikirinさんからの引用を思い出しましょう。グローバル化とは、世界の多様性を受け入れること、そしてそれらを持った人達を意思決定や組織運営を共に行う仲間として迎え入れること、です。

日本におけるグローバル化を想像した場合、それが、日本人に混じって白人がいて、皆が英語を話しているものであったとすると、ここにおける多様性とは、人種の違いであったり、母国語の違いだったりです。日本人は、それを受け入れたのかどうかは別にして、とりあえず相手の母国語であろう英語を話していると想像したと思います。オフィスを想像してた場合は、何かを決めるためのミーティングをしているのを想像していたと思います。ですので、ここにおける日本人は、少なくとも自分とは違う人種や言語を受け入れて、何らかの意思決定をしていると言えるでしょう。なので、その人にとってその場はグローバル化された場でしょう。

しかし逆はどうでしょう。その場の白人は、自分とは違う人種と一緒にいます。多様性を受け入れているのでしょう。しかし、言語に関しては自分の言語を使っています。恐らくその場の日本人が英語を母国語としない事を知っているでしょう。しかし自分の母国語を使っています。

海外におけるグローバル化を想像した場合、それが、白人に混じって日本人がいて、皆が英語で話しているものであったとすると、ここにおける多様性は以前と同様に、人種の違いであったり母国語の違いであったりです。白人は、それを受け入れたのかどうかは別にして、自分の母国語であろう英語を話しています。オフィスを想像していた場合は、何かを決めるためのミーティングをしているのを想像したと思います。ですので、ここにおける白人は、少なくとも何らかの意思決定に日本人を受け入れているといえるでしょう。しかし言語は英語です。

逆はどうでしょう。その場の日本人は、自分とは違う人種と一緒にいます。多様性を受け入れているのでしょう。言語も相手の母国語であろう英語を話しています。グローバル化ですね。

さてここで両者の差に気づいたでしょうか。白人は受け入れていないものがあります。日本人は受け入れていないものはありません。この差は何でしょうか?つまり、日本人はグローバル化によって自分達がしている事を、相手にはしてもらえてません。では相手はグローバル化じゃないのでしょうか?そうは思わないはずです。

となると、日本人にとって、グローバル化によって得られる事よりしないといけない事の方が多いのです。しかも日本人はそれを自分の意思でやっているのです。凄く損です。

もっと簡単な例を出しましょう。白人の彼氏/彼女がいる日本人、と聞いてその二人を想像してみてください。日本人が英語を話して、白人は日本人が喋る英語ほど日本語を話せていない事はないですか?もしそうなら、なぜそうなのですか?白人は、日本語を受け入れたくないんです。しかし日本人はそれを不公平だと思わないのです。それが当たり前だと思うのです。

しかしもしそれが日本人とベトナム人のカップルだったらどうでしょう?日本人がベトナム語を話しているのを想像しましたか?それともベトナム人が日本語を話しているのを想像しましたか?そしてそれを想像したのは何故ですか?もしくは、その二人が日本人と韓国人だったらどうですか?

もし本当に、グローバル化が多様性を受け入れる事だと思うのであれば、相手も自分に対してそうするはずです。しかしそうでないのであれば、相手はあなたに接する事をグローバル化だとは思っていません。自分の文化を受け入れてくれる人、なのです。もっと言えば、自分に都合の良い人なのです。自分の文化は受け入れてくれるけど、自分に相手の文化を受け入れることは要求しない。そんなに都合の良い人はいないのです。

相手は自分の文化を受け入れてくれないのに、自ら進んで相手の文化を受け入れるのは、自らの意思で迎え入れる文化の侵略です。

rocoを使ってnodeのアプリケーションをdeployする

railsのアプリケーションをdeployするにはcapistranoが定番ですが、nodeのアプリケーションをdeployするには何を使うのが良いのでしょうか?最近はnodeのアプリケーションをホストしてくれるサービスが沢山あるので (node-ninjanodejitsuなど) それらを使うのも有効だと思いますが、もし自分の環境にnodeをインストールして、そこでnodeのアプリケーションをホストしたい場合において、rocoを使ってdeployする方法を紹介します。

rocoはいわゆるcapistranoの様なもので、特定のサーバにsshしてあのコマンドを実行してそのコマンドを実行して、というのを自動化するものです。作者の方は、RailswayJSの方だと思います。nodeのwikiでdelpoymentの項目を見て全て見てみたものの、rocoが一番私の理想に近かったので今回はrocoを選びました (substackのpropagitもかなり魅力的です) 。

私が欲しかったのは、nodeの事をあんまり知らない人でも、比較的簡単にコマンド一つでいつでもどこからでもdeploy出来る、というものです。rocoを使った私のdelpoyment scriptは以下の様な感じです。

基本的には、rocoが殆ど提供しているdelpoymentに必要なメソッドを、必要に合わせて自分で上書きするだけです。例えば、rocoはupstartを使ってnodeのアプリケーションを走らせるメソッドを提供していますが、私はそれをforeverを使う様に変更しました。後、rocoはpackage.jsonを見て、どこがレポジトリなのか等を判断します。上記のdeployment scriptを使ってdeployする場合は、"roco deploy:setup"を走らせた後、"roco deploy"を走らせるだけでdeploy出来ます。rocoはrollbackも出来るので、前のdeployに戻したい場合は、"roco deploy:rollback"で前までの環境に戻せます。

上記のdeployment scriptは、恐らく何をしているのか理解するのがそれほど難しいものではないと思いますが、一般的なdeploymentにおいて引っ掛かった点がいくつかあったので、それらに対する解決策を書いておきます。

sshの鍵

  • 自分のローカルの環境からdeployする場合は、delpoy先のサーバがpackage.jsonで指定されたrepositoryにアクセス出来る必要があります。つまり、repositoryがgithubの場合、deploy先のサーバからgithubにアクセス出来ないといけません。
  • この時、deploy先のサーバでssh-agentを走らせておいて、鍵をssh-addすればいいのですが、rocoはコマンドを実行する際にinteractiveなsshではない方法でコマンドを実行します。つまり、~/.bashrcなんかは読み込まれずにコマンドが実行されます。よってssh-agentを走らせたりssh-addしたりが面倒になります。
  • なので、私は/etc/ssh_configのForwardAgentを"yes"にして、自分のローカルの環境で足されている鍵がそのままdeploy先の環境でも使えるようにしました。linuxの場合、keychainを使うと複数回ssh-agentを起動したりしなくてすむのですが、どちらにしてもrocoがコマンドを実行する度にまず最初にsource ./keychain/`uname -n`-shしないといけません。

nave

  • 私はnaveを使っていたのですが、naveは新しいshellを起動します。rocoがコマンドを実行する際に、naveを実行すると、新しいshellになってしまうのでそこが上手くいきませんでした。なので、nvmに変更しました。

以上です。後は、rocoはあんまりドキュメントがなかったのでコードを見ながらやる事になり、面倒でした…。しかし、sshのポートが指定出来ない問題をレポートすると、すぐ即日に修正されていたり、作者さんは見ている感じなので、とりあえずはrocoを使ってみて様子を見てみようと思います。

tmuxでセッションを共有する

最近tmuxを使い始めたのですが、同僚から非常に便利な使い方を教えてもらいました。

職場では頻繁にペアプログラミングするのですが、各々のラップトップとひとつの大きいモニターがあります。どちらかのラップトップをモニターに繋いで、モニターをメインにして、ひとりはラップトップでマウスとキーボードを、もうひとりはモニターに繋いだ (もしくはモニターに繋いだラップトップに繋いだ) マウスとキーボードを使います。これで二人が同時に、排他的に同じスクリーンを操作出来るのですが、私はラップトップが目の前なのでそっちのスクリーンを見る方が楽で、モニターを見るには首を曲げて観ないといけないので姿勢が気になりました。

そこでtmuxのセッションの共有です!tmuxでスクリーンが共有出来ると、私は自分のモニターを見ながら作業していても、ちゃんと私が見ているのと同じスクリーンをモニターなり相手のラップトップなりで見れるようになります。これは素晴らしい。

方法は簡単で、まず片方がtmuxをソケットを指定した形で起動します。

   $ tmux -S /tmp/tmux.session   

ソケットのパスは自分の好きなもので大丈夫です。次に、もう片方の人に、既にtmuxを起動したマシンにsshで接続してもらいます。そして、先程指定したソケットにattachする形でtmuxを起動します。

   $ tmux -S /tmp/tmux.session attach   

すると、両方のターミナルで同じものが見えるようになります。

まだtmuxを使いこなせていないので、まだコピペとかが面倒な感じがしていますが、とりあえずtmuxによるセッションの共有は便利なので、是非ペアプログラミングなどに使ってみて下さい。リモートの人同士なら、共有のありがたみも増すかも知れません。

アジアコミュニティがjeremy linに期待するものと、日本人のスタートアップがシリコンバレーに期待するもの

最近、jeremy linという中国系のNBAの選手が凄く注目を集めている。詳しい事は既にちかさんが書いているので、引用させて頂きます。

シリコンバレーはPalo Alto出身で、ハーバード大学卒、台湾系NBA選手。ハーバード出身のNBA選手は60年ぶり、アジア系選手はNBA史上数名しかいない、というだけでも珍しい。

その上、大学進学時にはバスケ奨学金はもらえず、プロになるときはドラフトされず、やっと入ったチームもすぐにクビ、次のチームもクビ、なんと1年で2チームを首になり、3つ目もあと数日でクビになりそうだった、という見事な下積みキャリアであった。

ところが、先週になって突然大活躍しだし、連日NBAの記録に残る実績をあげ、Kobe Bryant属するLakersとの試合でも、Kobe Bryantより点を入れてチームを勝利に導く。NBA史上、ここまで無名な人がここまで急激に活躍することはかつてないっ、ありえないっ、ということで、ラストネームのLinとinsanityを掛けて、Linsanityという造語ができた。

要は、アジア人が活躍出来ると思われていなかった泥臭い男のスポーツ(アイススケートなどではアジア人の活躍もあると思うが、女性が主だったり、男性でもそのスポーツが物理的な力などを象徴するものは少ないと思う。勿論、室伏を除く。)で、アジア人が彗星の如く現れて大活躍、という事である。しかし私はスポーツなど好きでもない。それなのに何故私も彼に注目しているのか。

私もそこまで詳しくはないのだけど、少なくとも米国のアジア人が彼を、アジア人として応援しているのが目に入った。私はそこに、ずっとアジア人には出来ないと思っていたり思わされたりする事で、なんらかしらの劣等感を感じていたが、それを覆せるかも知れない彼に、それを実際に覆して欲しいと期待している様を感じた。

国や人種にはよく、どこの人はなにが得意で、あそこの人はなにが得意で、みたいのがついて回る。日本人なら数学が出来るとか、ドイツ人はエンジニアリングが得意とか、そういうものである。実際にそれにならった様な結果があるから、それらの言われが途切れずに続くのだと思うが、私はこれには二つの理由があると思っている。実際にその言われの通りの能力がある事と、それも去ることながら、そういう言われが故に、自分はそれが出来るんだというのを疑わない事である。

出来るかどうか分かっている状態で挑戦するのと、出来るかどうかすらが分からない状態で挑戦するのは大きく違う。前者の場合、多少出来なくても、もっと練習すれば出来るようになると思うだろうし、そうなる事を疑わないだろう。後者の場合は、出来ない場合に、出来ないのは自分だからなのか、練習が足りないからなのかを判断するのが難しい。勿論後者の場合であっても皆が皆諦める訳ではないが、出来ない状態が続けば諦める人は多いと思う。前者の場合でも勿論出来ない状態が続けば諦めるのだろうが、前者の方は、出来ると信じてやまないので、後者よりも長く続ける人は多くなると思う。

アジア人は、皆俺にバスケなんか出来ないや、と思って諦めてきたのである。そして周りも、アジア人にはバスケは出来ない、と思ってきたのである。そしてそれがどうでも良い事ならどうでもいい。しかしバスケは、一番じゃないにしろ人気のあるスポーツである。見る人は多い。当然、アジア人でも見る人は多いだろう。しかしそこにアジア人はいない。人気のあるものに、自分と同じ人種はいないのだ。今なら、テレビを見てもアジア人がいない事はないが、テレビを見てもアジア人がいないのを想像すれば、それが見ているアジア人をどういう気持ちにさせるのか想像しやすいかもしれない。

そこにjeremy linが登場したのだ。アジア人なのに、バスケで大活躍している。linsanityという造語まで出来て、彼の出ている試合では終始彼が画面に映し出されるのだ。彼の生い立ちや色々な彼に纏わることが放送され、皆が興味津々なのである。アジア人にとってこんな事は今まで無かったのである。つまり、出来るかどうかすらが分からない状態で挑戦してきて、今までアジア人には出来ないと思って諦めていたものが、そうではないんだという認識に変わりつつある過渡期にあるのだ。私には、この様な過渡期を凄く期待しているフィールドがある。

最近は日本でも、シリコンバレーに見る数々のスタートアップの大成功に憧れ、同じように日本であるいは米国でスタートアップを始める日本人を知っている。それに伴って(または逆なのか?)、日本の投資家もそういった状況を後押ししようと頑張っている。去年のtechcrunch disruptでは、日本人が非常に多かったと聞いているし、職を探している時に応募したサンタモニカのスタートアップでも、得た投資の多くが日本人の投資家からのものだったと聞いた。しかし、今のところ、まだ誰でも認識しているような、大成功を収めた日本人によるスタートアップはまだないと思う(勿論少なからずあるけど)。そしてその背景には、出来るかどうかすら分からない状態での挑戦があると思っている。

大成功を収めた例がないが故に、大成功を収める事が出来るのかどうか分からない。挑戦する側にとってもそうだが、投資する側も、過去に事例がないとなると、お金を出したくないのは当然である。逆に米国では、今では既に過去に大成功した事例が沢山あるので、出来るかどうか分かっている状態で挑戦しているのであり、やる側も出来ると思うしそれを信じてやまず、そして投資する側もそれを疑わない。

私は最近、多くの日本人のソフトウェアエンジニアの方々と知り合ったが、彼らは非常に優秀である。勿論皆がみんなではないだろうが、それは米国とて同じである。少なくとも私は、日本のソフトウェアエンジニアは、ソフトウェアエンジニアとしての能力に関して、大成功するスタートアップのソフトウェアエンジニアのそれと遜色ないと思っている。つまり、能力の点においては、出来るかどうかは分かっている。しかし、まだ実際に大成功したスタートアップがないが故に、日本人でも出来るというのを信じてやまない、という部分はまだ確率出来ていないと思う。

これを確立するには、実際に大成功するケースを出していくしかない。つまり、日本人でも出来るんだ、というロールモデルが必要なのだ。日本では、米国人は良く挑戦してうんぬんというのを聞くが、米国人とて、もし出来るかどうか分からない事があるならば、そこまで挑戦しないはずである。挑戦するのは、挑戦して成功したケース、つまり成功したロールモデルがあるから挑戦してみるのだ。出来るのが分かっているから挑戦するのである。それを、出来るかすら分からない状態での挑戦をしているのだと勘違いすると、そりゃ凄い挑戦をしているなぁと感じるものである。

かなり無駄に長くなってしまったけれど、米国のアジア人がjeremy linに期待するものと、日本人がシリコンバレーでの日本人のスタートアップの成功に期待するものは、凄く似ているのだ。そして、今後jeremy linの活躍によって米国のアジア人がどう反応するのか、米国の人達がアジア人をどう見るようになるのか、それを追うこで、今後日本人のスタートアップの活躍によって日本人がどう反応するのか、米国の人達が日本人のスタートアップをどう見るようになるのかが見えると思っている。そして私はそれらに、非常に興味がある。

 

街の探索

新しい職場になり、今までのsanta monicaから少し北のpacific palisadesという街で働くことになりました。この街は全然知らなかったので、少し探索してみました。

(download)
pacific palisadesは、典型的な海沿いのお金持ちが多い街で、豪邸やプライベートな道があったりします。pacific palisadesのdowntownは凄く小さいですが、カフェなんかが色々あってかわいい雰囲気です。海沿いに出ると、もう海ばっかりです。

ついでに、近くだけど全然探索していなかった、veniceを少し探索してみました。

(download)

今回はまず嫁がマカロンを食べたいとの事で、マカロンを売ってそうなところをyelpで探しました。すると、jin pastrieという小さなお店を見つけました。そこで売っていたマカロンは、小さくてお洒落で、日本のお店みたいでした。veniceは、いわゆるヒップスターが多い街なのですが、確かにこの感じは日本っぽい感じもあるなぁ、と思いつつ、帰ってお店のサイトを見てみると、オーナー兼パティシエの方は、シンガポールの方だけど日本で色々お菓子を勉強した方なんだそうです。なるほど。

そしてそのお店が綺麗でもっと他のお店も見たくなったので、ちょっと探索してみました。するとまたオーナーが日本人の雑貨屋さんを見つけました。まあveniceなので、高いものが多いのですが ($100の鉛筆削りとかあった…)、日本の雑貨屋さんそのもので凄くワクワクしました。裏にあるレンガ造りの店構えもお洒落。

veniceは、以外に日本人には雰囲気や文化が似ているのかもと思いました。

layoffと新しい職場

最近私は、人生で初めてのlayoffを経験しました。layoffの二週間前に、二週間後にlayoffになる旨を伝えられました。その時は、まじか、と思いながらも、まさか自分がlayoffされるとは、と思っていました。一緒にもう一人の同僚がlayoffになったのですが、彼はもう失業保険を申請する気満々で、私は二週間の内に仕事を探す気でした。

この旨をツイッターでつぶやいたところ、色々な方々から求人の旨を教えてくれたりして頂けました。ツイッターの力を見くびっていました。

今回は、とりあえずlayoffされる前の二週間で仕事を決めたい、というのが最優先だったので、ほぼ次の日から仕事探しを始めました。普段は使わないのですが、CTOや同僚が紹介してくれたリクルーターも使ってみました。リクルーター、恐らく彼らがかなり凄く出来るチームだったからだと思うのですが、彼らは凄かった。もう次の日から面接の嵐。layoffの話があった時に、向こう二週間で仕事を探そうと思うが、面接なんかで仕事が出来ない時間があっても良いか?、と聞いて、それは大丈夫、との確認を貰っていたので、好き勝手に面接させて貰いました。

まず最初に驚いたのは、rails開発者 (railsを使って開発する人) は需要が多い。まあそれは知ってはいたのですが、実感するとそれはそれで凄く信頼性が増します。後は、LAにもスタートアップは結構あるという事。名前も聞いたことないものから、多少名前を知っているものまで色々ありました。これはかなり面白そうだ、というのもあったり、サンタモニカのgoogleがveniceに移ったり、最近あの辺がシリコンビーチと呼ばれている理由を少し実感しました (veniceには、ycに投資されているgrubwithusearbitsなどがあります) 。

残念ながらnodeを主に使っている会社はあんまりなく (ハリウッドにはscopelyというnodeを主に使っているscopelyというスタートアップ (今のgoogle adsenseをgoogleに売った人がやっている) や サンタモニカにはmiso mediaというnodeに以降を考えているスタートアップはある (聞いた話だと、最近得た投資は日本の投資家からのものが多かったそうだ) ) 、nodeを使った仕事は最優先なものリストからは外しました。

今回は本当に色々な方々から色々な機会を紹介して頂いて、本当に嬉しかったです (一緒に本を書いている方や、socket.ioで有名な若きスーパーハカー、等々…) 。しかし今回は期待していなかったlayoffな事が大きく、二週間以内に探す、というのを最優先にしました。なので、遠くまで面接に行ったりなかなか出来ませんでしたが、layoffされて二週間以内で仕事を見つけることが出来ました。

Img_0446
今回は初めてのメディカルの業界です。職場は場所に恵まれていて、職場からは海が一望出来ます。小さなスタートアップですが、皆シャープでこれから楽しみです。そしてなんと、layoffされた我々に釣られてか、前の職場で一番出来る若い同僚も一緒に働くことになりました。彼も前々から新しいところに行きたいと思っていたらしく、丁度これをいい機会と見たそうです。

という事で、layoffと新しい職場が見つかるまでの短い、けれど凄く濃い期間の話でした。

the coveを観て思った事

the coveという、日本の太地町で行われているイルカ漁に関するドキュメンタリーを観ました。非常に興味深かったのと、考える事も色々あったので、自分が興味深かった事を書きます。

まず私は、最近まで日本でイルカを獲って食べる地域があるのを知りませんでした。私がこれを知ったのは、UCLAの近くの良くデモをしている場所で、ある日"shame on japan! stop eating dolphines!"みたいな紙を見た時でした。その時は、日本でイルカなんか食べるか?、と思いましたが、どうやら食べるそうです。和歌山県の太地町というところは、世界に対してイルカの配給元として有名で、水族館なんかにいくイルカもここで捕まえたものを買うのだそうです。生きたイルカは、$150kくらいで取引されているそうです。

まずこのドキュメンタリーを作った人達が達成したい目的は、イルカをこれ以上殺さない事です。これを達成するために、太地町で毎年9月に行われる漁を止めようとしたり、色々な事をするのですが、最終的に彼らがとったのは、ドキュメンタリーを作ることでこのイルカ漁の事をもっと知ってもらい、より多くの人にこのイルカ漁に反対してもらおうという事でした。ソフトウェアエンジニアとして興味深いのは、以下の部分でしょう。

映画の製作にはシリコングラフィックス社やネットスケープ社を創設したジム・クラークが500万ドルの資金を提供しており[2]

ドキュメンタリーは非常に面興味深く、時間を忘れるくらい見入ってしまいました。主演のリックは、映画フリッパーで使われたイルカを調教していた人で、彼はイルカが大好きです。しかし、彼が関わった映画であるフリッパーが大成功したために、当時3つしかなかったイルカのいる水族館はどんどん増えました。彼は、フリッパーで使ったイルカが映画の後自分の目の前で自殺(彼曰く、イルカにとっての呼吸は人間にとっての呼吸のようなものではなく、自発的なものなので、呼吸をしない事を選択する事で自殺出来るそう。そして彼曰く、そのイルカはそれを選んだそうだ。)したのを受け、彼は彼自身がその発展に大きな貢献をしたイルカを扱った業界を、彼自身の手で壊すことを望んでいる。二度とイルカが同じように死なないように。しかし太地町の漁師は、彼らがその漁の写真を撮ることはおろか、街に居るだけで彼らの後をつけたりするそうです。

彼らはドキュメンタリーの中で、

  • 政府が彼らに、イルカが魚を食べ過ぎて困っているから"pest control(害虫処理)"して欲しいと依頼している
  • 日本に住む人でもイルカを食べる地域があるのを知らない人は多い。これはメディアがそれを公にしないため。イルカの肉は、イルカの肉としてではない形で市場に出まわっており、メディアがイルカの含む水銀の問題を公にしないようにしている(イルカに含まれているイルカは食物連鎖の頂点なので水銀を多く含んでいる、というのは良く聞く)
  • 太地町の漁師たちは、彼らを殺せるなら殺そうとしている。警察もぐるになって追跡してくる

の様な主張をします。まあ実際、日本の事を何もしらない人が、あれだけ見せられたらそれらは真実に見えるでしょう。私もいくつかは真実だと思いましたが、大げさに表現されている部分も多々あるように思いました。

彼らは、このドキュメンタリーを見せることによって、日本においてもより多くの人をこのイルカ漁に反対する事に賛成させる事が出来るでしょう。しかし、私は彼らの目的、イルカを殺したくない、という部分は理解出来るけれど、その目的を達成するための手段はさほど有効ではないと思っている。

まず太地町の漁師たちがなぜイルカを捕るのか。理由は簡単なはずで、単にそれによる収入がないとやっていけないからだと思う。ドキュメンタリーから見るに、漁師たちは彼らが漁の様子を公にしようとするのを非常に嫌がっている。中指を立てるし、英語で出て行けと書いた紙を見せつけたり、罵声を浴びせたりしている。漁師が英語を頑張っているのだ。それはもうそれなりの理由があろう。そしてそれは、お金であるはずだ。

ならば、彼らがやれるより効率的な運動は、このドキュメンタリーを見て彼らに賛成する人から募金を募り、太地町の人達にそのお金をあげる事だ。漁師たちとて、漁をせずとも同等のお金が手に入るならしないと思う。ドキュメンタリーでは、"漁をせずに同等のお金が貰えるなら、漁はしないか?"、と質問し、"する。これは文化だから。"、と答えているシーンがあるが、そんなはずはない。漁師たちはもう、彼らになんらかの肯定を示す事で、鬼の首を取ったかのようにそれを利用されるのが嫌なだけに見える。そうなった状況で、話し合いなどなかなか難しい。

結論として、私は太地町の漁師に、イルカ漁で設けている分だけお金をあげれば、イルカを殺したくないという目的は達成出来ると思う。そして彼らのドキュメンタリーには、人々をその方向に持っていくだけの魅了はあると思う。

どうにしろ、日本に生まれて15歳まで育ったが、それでも日本においてイルカを食べる地域があるとは知らなかったし、ここで捕まったイルカが世界中の水族館で見るイルカなんだとは知らなかった。

修正: connect 1.8以降でファイルのアップロードを処理する

以前、connect 1.8以降でファイルのアップロードを処理するで紹介した、connect 1.8以降を使ってアップロードされたファイルを処理する方法ですが、間違っていました!

このようなフォームがあった場合に、

この様に、req.bodyを使ってファイルにアクセス出来ると書きましたが、req.bodyではなくreq.filesでした。

自分で試さずに書くものではないですね。

javascriptだけでwebcamからストリーミング

先日、衝撃的な記事を発見しました。javascriptだけで、webcamにアクセスし、ストリーミングしているというのです。しかもandroidのウェブブラウザから、androidのカメラにアクセスしているではありませんか。なんだこれは。幸い、彼はコードを公開してくれているので、それを見てみる事にしました。

どうやら、WebRTCのgetUserMediaというapiをOperaが実験的に実装しており、それを使うとそのapiを使うことで、webcamにアクセス出来るようです。しかも、webcamからキャプチャーした画像を、そのままcanvasにコピーする事が出来ます。勿論、勝手にコピー出来てしまうと嫌なので、about:configからその機能を有効にしないといけないのですが、canvasにコピー出来るということは、そのキャンバスに描写されているデータをtoDataURLで取得出来る事になります。そして、そのデータをwebsocketでサーバに送り、サーバ側からそのデータをクライアントに送信すると、webcamから取得した画像が転送出来る事になります。webcamからの画像の取得を頻繁に行い、それらを頻繁にサーバに転送し、サーバもそれらを頻繁にクライアントに送信出来れば、あたかも動画の様に見えます。 各々が簡単に試せるために、記事を参考にしながら書いたコードをgithubに載せてあります。是非自分で試して見てください。非常に感動します。

ひとつ残念なのが、toDataURLで取得したデータはbase64エンコーディングされています。つまり、バイナリの3/4のサイズになってしまいます。折角なので、前回の記事でコメントを頂いた@gtk2kさんのパッチを使って、画像のデータをバイナリで送信したかったのですが、canvasからバイナリのデータを取得するtoBlobが、少なくともOperaでは実装されていませんでした。もしこれが実装されれば、webcamからの画像をバイナリで取得し、バイナリのままwebsocketでサーバに送信し、バイナリのままクライアントがデータを受け取れる事になります。非常に楽しみです。 という事で、deviceタグの実装よりも先にそれらしいものが出てきそうなWebRTCの話でした。

websocketでバイナリデータの送受信

最近chromeで、バイナリデータの送受信をサポートしたwebsocket apiが実装されました。現時点 (2012/12/5) で、実際にバイナリデータを送受信出来るwebsocketのライブラリはあるのでしょうか。調べてみました。ここでは、ブラウザとサーバ間における、websocketを使ったバイナリデータの送受信に限り、ブラウザからはarraybufferを、サーバからはBufferを、バイナリデータの型として使用します。

 

socket.io

まずは本命のsocket.ioです。0.8.7で試してみました。

かなり端折りましたが、ブラウザとサーバのコードはこんな感じです。そして結果はこんな感じです。

(download)

ブラウザから送信したデータもバイナリとして認識されず、サーバから送信したデータもバイナリとして認識されていません。

 

websocket.io

そこで次のwebsocket.ioです。0.1.1で試してみました。

こんな感じのコードです。そして結果はこんな感じです。

(download)

ブラウザから送信したtypedarrayが、ちゃんとサーバ側でBufferとして認識されています。これは素晴らしいですね。しかしサーバから送信したBufferは、バイナリのデータとして認識されていません。残念。

 

websocket-node

最後にwebsocket-nodeを試してみました。1.0.2です。

コードはこんな感じです。ほとんどサンプルのままなのですが、READMEにはバイナリデータの送受信が出来る事を謳っているので期待大です。結果はこうでした。

(download)

ブラウザで送信したtypedarrayが、サーバでBufferとして認識されています。そして、サーバから送信したBufferが、ブラウザでarraybufferとして認識されています。素晴らしい!

 

結論

  • socket.ioは、送受信ともに出来なかった。
  • websocket.ioは、送信は出来たが受信は出来なかった。
  • websocket-nodeは、送受信ともに出来た。

恐らくsocket.ioも近いうちにバイナリのデータの送受信をサポートすると思いますが (commit logにはサポートしたとあるが…) 、現時点でこれらの三つを比べた場合、websocket-nodeのみが、ブラウザとサーバ間でバイナリのデータの送受信が可能、という事のようです。

テストに使用したファイルのリンクを以下に貼っていますので、socket.ioやwebsocket.ioでも出来るぞ!、という方は是非教えて下さい。

後、鵜飼さんのポストも参考になります。