リスクって何?

On Off and Beyond: リスクをとる
を読んでいたら、リスクに付いて少し考えたので、考えた事を書き出します。

1)僕のリスクの定義:チャレンジに伴い、失うかもしれない物亊

2)リスクに付いて語られる時は、メインにお金に付いて語られる。しかし、リスクにも、リターンにも、お金以外の、リスク、リターンもある。リスクでは、精神的な苦痛が増える可能性がある、など。リターンでは、経験が得られる、箔が付くとか、やりたいことがやれる、そこに夢があるとか、チャレンジしている自分が大好きとか、色々とあるわけです。そうのようなお金以外の部分も含めて考えて、リスクを取って行動出来ないケースも多々あると思いますし、金銭的なリターンが少なくても、チャレンジ出来るケースも多々あると思う。要するに人それぞれかな?

3)自分にとってはリスクと思われる事も、他の人にとってはリスクではなくチャンスだととらえている人もいる。最近のアメリカでは持ち家バブルが弾け家の値段が下がっている。多くの人はもっと下がるかもしれないから(リスクが高いから)、買い控える。一方、この値段が下がった時を狙って、家・土地に投資をしている人もいる。本当にいる。色々な考え、状況の人がいて、リスク・リターンの定義って人によって違うのでは。

4)今日まで、ミドルリスクを取ってきたが、金銭的に大きなリターンは今の所得ていないなー。でも歩んできた人生には満足している。

5)最後に、やっぱりリスクを取る為には、その先にに夢(色々なものを含む)かがないと、リスクは取れないでしょ。その夢がリスクを取る際に頭の中に可視化出来るリターンであり、夢がリスクより大きくないと、リスクを取って行動できないと思うな。

if dream > risk:
    take a risk and challenge;
else:
    pass;

キャプションの重要性

先日、I Can Has Cheezburger?の、創業者の話を聞きに行って来た。I Can Has Cheezburger?は、下記のようなおもしろ猫写真共有サイトである。2007年1月に二人で始めて、今では1日あたらい8000の猫写真のポストがあるサイトに成長した。創業者二人の話は、どんなきっかけでこのサービスを始めたのか、アクセスが急に発生、サーバーの問題が発生してパニックになった、ウエブ2.0的な機能を実装したなど、どのようにサービスを成長させてきたのかを時系列にしたがって話してくれた。

話を聞きながら考えた事なのだが、I Can Has Cheezburger?が成功したのは、「写真の上に付けられているキャプションがおもしろいからなのでは?」と考える。おもしろい猫の写真はウエブ上にごろごろしているそうだ。多分、おもしろい猫の写真だけではユーザーは笑ってくれないであろう。笑ってくれるかもしれないが、リピーターにはなってくれないであろう。おもしろい猫の写真にさらにおもしろいキャプションが付いているから、ユーザーは笑うし、もっと見たいという気持ちになるのではないか?

I CAN HAS CHEEZBURGER?
more animals

lol – laughing out loud

Jason Fried – Things We’ve Learned at 37Signalsより

Jason Fried – Things We’ve Learned at 37Signals 今日読んだ中で一番のブログ。Jason FriedはBase CampやRuby On Railsで有名な37Signalsの共同創業者です。内容はタイトルの通り、彼が37Signalsの経営から学んだノウハウが書かれています。その中で一番気になった点を書きに引用します。

7. Focus on what doesn’t change – The technology and software business seems to obsess with what is in flux and changing. Always new stuff. New languages and frameworks. Focus on what doesn’t change and think about the things that matter today and will matter 10 years from now. “Speed is a really important thing for our products. 10 years from now people will still want speed. We could make a Facebook app or we could just make things faster – so we make things faster.” Reinvest in the things that don’t change. Competitors will chase the next big thing.

下手くそな訳ですがどうぞ

(訳) 7. 不変な物に注力しなさい- テクノロジーやソフトウエア・ビジネスは流動的で変化が激しいと思われている。いつも新しい物を追い求めている。新しい言語、新しいフレームワーク。新しい事を追い求めるのではなく、不変の物に注力したらどうだろうか?現在も問題であるが、10年後も問題であり続けるような事を解決するのはどうだろうか?”スピードは私たちのプロダクトにとって大変重要です。10年後も人々はより速いものを追い求めているだろう。今私達はFacebookのアプリを作ることも出来るし、スピードを改善する事もできる ー それで、私達はスピードを改善させる事を選んだ。”不変な事に再投資するべきだよ。競合相手は新しいものを追い求めていると思うけど。

この部分を読んでいて、この前GoogleがリリースしたChromeブラウザーで感じたスピードと繋がった。Googleがいつも追い求めている物の一つはスピードである。検索結果を返すスピード。検索の為のインデックスを更新するスピード。ウエブページを早く表示するスピード。ネットワークでの通信速度。その他の不変な物への注力としては、1)検索結果の質、2)gmailで見られるディスク容量、3)データのバックアップ、Googleファイルシステムによるレプリーケーションによりデーターのバックアップがいくつも作られている、4)多くの無料サービス、これはいつの時代も求められると思う。その他にも色々あると思うが。Googleは不変的な物へ注力する事によって人々を引きつけている。

Googleによって裏付けられた、Jasonの僕らへのアドバイス、次はこのアドバイスをどう生かすかだ。

デキルヤツノ条件

僕が、ここ数ヶ月、毎週楽しみに待っているウエブ記事が降旗 学さんが書かれている、「デキルヤツノ条件」。面白い、そして為になる。今週の記事は一段と為になったと感じた。多分、宋文洲さんへのインタビュー記事であるからかもしれない。人によって感じ方は違うかもしれませんが、お勧めです。一番為になるところは6ページ目なのですが、1ページ目から読んだほうが、6ページ目の価値が増すと思います。

24:己を知るために、屈辱の杯を飲み下す

6ページ目の二人の会話より:

「成功というのは、誰もが達成できるものじゃないから成功なんです」

「でしょ。平均を成功と言う人はいないから、平均の人ができていないことをするのが成功なんです。ということは――」

「成功するためには、平均のことをやってちゃいけないってことなんですよ。みんなと足並み揃えて同じことをやってるようじゃ差なんてつけられない。みんなと同じテキストを読んで、みんなと同じ空気を読んで……、わかりますよね。既成概念を打破してやろうとか、誰もやったことのない突き抜けたことを試みてみようとかしないと」

YouTube: 堀江淳 – メモリー・グラス

世界には、笑顔で頑張っている人が多くいる

【ニコニコ動画】沸騰都市 03 「ダッカ 奇跡を呼ぶ融資」
時々、仕事や勉強に対する気持ちを維持するする事が辛い時があるが、この番組で紹介されている人々の笑顔で働いている姿を見ると、自分ももう一頑張りしないとな、という気持ちになる。おすすめです。

【ニコニコ動画】沸騰都市 03 「ダッカ 奇跡を呼ぶ融資」

Mattが来た

↓↓↓JerryとMattが一緒に踊ってるよ。↓↓↓
YODEL: And now we dance
Dancing at Yahoo!

Mattが来るらしい Mattが来た。

用事があったので参加できなかったが、Flickrにビデオが載っていました。

ちょっと前に書いた、Matt(Where the Hell is Matt? (2008))が来週月曜日に会社に来るらしい。一緒にダンスするチャンスもあるみたい。これはお昼時だし行くしかないなー。

追記1:げー、月曜日1時から予定があった。なんとか予定ずらせないかなー。
追記2:同僚二人に「Mattが来るんだって」って話したら、だれそれって言われた。
追記3:結局、用事があって参加できなかった。一緒にダンスしたかったなー。残念。7月21日(月曜日)

I miss Cambridge, MA.

Cities and Ambition

One of the exhilarating things about coming back to Cambridge every spring is walking through the streets at dusk, when you can see into the houses. (略) In Cambridge you see shelves full of promising-looking books. (略)

2001年から2004年まで住んだケンブリッジの町(2005年から2007年は隣町のアーリントン)、すごく良い町だった、住むのが、そこで生活するのが、そこで出会う人々が好きだった。知的空間だった。学ぶ亊を町全体がEncourageしていた。街にDiversityがあった。チャールス川沿いの、JFKパークが好きだった。ハーバード大学の敷地も素敵な空間だった。街の喫茶店で本を読むのが大好きだった。ケンブリッジに住んでいる時に結婚した。ケンブリッジに住んでいる時に娘が生まれた。本当に良い町だった。またいつか住む為にケンブリッジに戻りたい。

知的能力を再生産する努力を続ける

まず入社して十年間は泥のように働いてもらう――丹羽宇一郎さん

の中のパラグラフ:

毎日深夜まで会社にいろとは言わない。本を読み、人と会い、ものを考えることで知的能力を再生産する努力を続けることだ。大変ですよ。ついて来られない社員が出ても仕方ない。

(僕が自分自身に付いて考えた事) 後々、自分自身の人生を振り返った時、後悔しない為には、ある種の成功が自分にとって必要である。その成功に少しでも近づく為には、日々勉強し続けなければならない。丹波さんの言葉を借りれば、「知的能力を再生産する努力を続ける」ということである。僕が一目置いている、または尊敬している人達は、絶えず勉強している。勉強したからといって、成功が保障されるわけではないが、勉強しなかったら、99.99%成功できないと思う。

翻訳:Use a Web Proxy for Cross-Domain XMLHttpRequest Calls

このエントリーは下記の翻訳です。ただ読むのもつまらないし、自分の血となり肉となるよう翻訳に挑戦。

JavaScript: Use a Web Proxy for Cross-Domain XMLHttpRequest Calls

JavaScript: クロス・ドメインXMLHTTPRequest呼び出しの為のウエブ・プロキシの利用
XMLHttpRequestオブジェクト(XHR)は、AJAXを利用したウエブアプリケーションの根幹となるオブジェクトです。しかし、ブラウザーによる、ドメインをまたがってのネットワーク・アクセス制限の為、クライアント・ウエブ・アプリケーションの開発は複雑です。このハウツーでは、単純なケースを用い問題点を説明し、一つの解決策(あなたのウエブ・サーバーから他のウエブ・サービスにリクエストを中継するウエブ・プロキシ)を提供します。

  • なぜプロキシが必要なのか?
  • Yahoo!ウエブサービス用のPHPプロキシ
  • 他の解決策
  • その他の情報

なぜプロキシが必要なのか?
全ての最新のウエブ・ブラウザーは、ネットワーク接続にセキュリティーの為の制限を加えている。その中にXMLHttpRequestも含まれる。この制限はスクリプトやアプリケーションが、元のウエブ・サーバー以外のサーバーに接続する事を禁止している。あなたのウエブ・アプリケーションとアプリケーションが利用するXMLデータが同じサーバーから来る場合は、この制限に含まれない。

しかしながら、あなたのウエブ・アプリケーションと、アプリケーションが利用するデータが違うサーバー(例えばYahoo! Web Services)から提供される場合は、ブラウザーは他のサーバーに接続する事を制限する。

この問題には、いくつかの解決策がある。もっとも一般的な解決策は、ウエブ・サーバーにプロキシを設定する方法である。XMLHttpRequestを使用し、直接ウエブ・サービスを呼び出す代わりに、プロキシに対して呼び出します。プロキシは呼び出しを実際のウエブサービスに中継し、そしてウエブ・サービスからの返答を、クライアントに中継します。ブラウザは、あなたのウエブ・サーバーに対して接続しているので、データはあなたのサーバーから返されます。

セキュリティー上の理由から、利用が制限されたウエブ・サーバーにプロキシをインストールする事は良いアイデアである。どのウエブサイトにも接続する開かれたプロキシは悪用にも開かれている。プロキシへの接続をあなたのアプリケーションのみに制限するのは難しいけれども、あなたはプロキシからの接続を指定したサーバー以外への接続を制限できる。接続するURLをプロキシ内にハード・コードしたり、オプションを制限することにより、あなた以外のアプリケーションにとって、利用価値を少なくする事が出来る。

Yahoo!ウエブサービス用のPHPプロキシ
Yahoo! Developer NetworkJavaScript Developer Centerにて、Yahoo! Search APIのためのPHPで書かれた単純なウエブ・プロキシを提供しています。あなたのウエブ・サーバーに、このプロキシをインストールすることが出来ます。

プロキシはグローバル・変数の中にHOSTNAMEという名前でYahoo!ウエブ・サービスのURLを組み込んでいる。あなたは、この変数をあなたが利用するウエブ・サービスに変更する必要があります。これはYahoo!ウエブ・サーチ・サービスに使われているドメインです。他のドメインにはYahoo!ローカル (http://local.yahooapis.com) や Yahoo! トラベル (http://api.travel.yahoo.com)があります.

define ('HOSTNAME', 'http://search.yahooapis.com/');

このPHPプロキシをあなたのクライアントアプリケーションから利用するためには、JavaScriptのコード内にあるウエブ・サービス・リクエスト用のURLに、ドメイン名以外のYahoo!ウエブ・サービスリクエストへのパスが含まれている必要があります。ドメイン名はプロキシにより付加されます。下記のコードは、JavaScript Developer Centerの、more complete XMLHttpRequest code sampleから引っ張って来ました。

// The web services request minus the domain name
var path = 'VideoSearchService/V1/videoSearch?appid=YahooDemo&query=madonna&results=2';

// The full path to the PHP proxy
var url = 'http://localhost/php_proxy_simple.php?yws_path=' + encodeURIComponent(path);
... // core xmlhttp code
xmlhttp.open('GET', url, true);

このサンプルではHTTP・GETを使用しているが、サンプルのPHPプロキシはPOSTもサポートしている。

あなたは、このプロキシを編集して、クライアントへの返答を、より扱いやすい形に変更できる。

他の解決策
プロキシの他にも、クロス・ドメイン・ブラウザ制限を回避するためのいくつかの方法がある。

  • アパッチのmod_rewrite、又はmod_proxyを利用し、あなたのサーバーから他のサーバーへリクエストを転送することが出来る。あなたのクライアント・コードからはあたかもウエブ・サーバー上にサービスがあるかのようにリクエストを送る。そしてアパッチがあなたのために他のサーバーへリクエストを転送してくれる。
  • JSONと、dynamic<script>タグをXMLとXMLHttpRequestの代わりに使用する。<script>タグの中で直接ウエブ・サービスを呼んでいるが、セキュリティーの問題を回避できる。もしあなたが使用するウエブ・サービスがJSONをアウトプット・フォーマットとする事が出来れば、ウエブ・サービスからのレスポンスをJavaScriptオブジェクトとしてeval出来る。このサンプルはJSON Documentationにある。
  • デジタルとしてあなたのスクリプトをサインする。Firfoxはあなたのスクリプトにデジタル・サインを当てる事ができ、そしてそれらのスクリプトはブラウザーにより信頼される。この方法で、FirefoxはXMLHttpRequestをたのドメインに対し使用できる。しかしまだ他のブラウザーはこの昨日をサポートしていない。

その他の情報
JavaScript、XMLHttpRequest, Yahoo! Web Service APIs、その他のJavaScript開発に関する情報は、Yahoo! Developer Network JavaScript Developer Centerを参照して下さい。

音楽とプログラム

長瀬弘樹という作曲家のことを読んで思った亊
前から思っていたのだが、自分が一目置いているソフトウエア・エンジニア・ハッカー・デベロッパー(コードを書く人々)の多くが、昔、音楽に力を入れていました、今も音楽しています、という人が多い。なぜだろう?ソフトウエア・ウエブ開発って、クリエイティブな部分があるから、音楽で養った・音楽ができる程の、クリエイティビティがソフトウエア開発に役に立つのかな?自分は昔から、リズム勘が悪く、歌を歌っても音程を外してしまうので、昔から音楽は苦手であった。小学校の頃、回りは皆、ベストテンとかトップテンとか毎週見ているのに、自分は見ていなかったり。中学校の頃、洋楽ブームてのがあったのだが、自分はハマっていなかった。僕も、音楽のセンスがあって、音楽にハマっているような人だったら、もっと良いエンジニアになれていたのかもってたまに妄想してしまう。

大学時代のメジャーは言語(英語)ですと言うアメリカ人の良いエンジニアにも結構会ったことがある。自然言語を深く理解する能力が、コンピューター言語で良いコードを書くのに役立つのかな?

当然であるが、メジャーは数学でしたというエンジニアは多い。スケーラビリティを必要とするアプリケーションを開発する為には数学の知識が役に立つ。