革新の余地がないマーケットなんてない

Google Chromeがリリースされた一昨日何人かの友人とGoogle Chromeに付いて話した。その時に考えた事。

友人との会話をする前の私のChromeに対する感想、速い、とにかく速い。これと同じ衝撃を受けたのは、FireFoxがリリースされた時以来。FireFoxのAlphaかBetaがリリースされる以前はIEを使っていたのだが、ブラウザー・マーケットはIEの独占でこれ以上のイノベーションは起こらないとなんとなく思っていた。しかし初めてインストールしたFirefoxのレンダリング速度はかなり速く、いきなりFireFoxの虜にされ、FireFoxに乗り換えた。今ではFireFoxのTシャツを普段着、仕事着として着ている程。そのFireFoxよりChromeは体感速度が圧倒的に速い。FireFox以前に受けた衝撃は、今思い起こすとGoogleの検索サービスのリリース。多分、初めてGoogleを使ったのは1999年頃だったと思う。Googleの検索結果の質は当時他を圧倒していた。あの時もその時使っていた検索エンジンを直Googleに切り替えた。Google以前は検索結果に表示されたリンクを全て頭から開いて、探しているものであるか見ていた。Googleは無駄な時間をかなり省いてくれた。僕は、時間を短縮してくれるイノベーションに衝撃を受けるのだなー。

友人Aとの会話から:まずは、「Google Chrome凄いねー」なんて、話をしていた。幾つかの会話の後、二人で合意にいたった事は、「Googleのテクノロジーに対するイノベーション力は凄い、他を圧倒している。」。そのイノベーション力は人材から?組織の仕組みから?文化的な問題?どうやったら張り合っていけるの?多くの疑問がわく。

午後、別の友人Bと話した。「Chrome凄いらしいねー」なんて、また同じ内容から話し始めた。幾つかの話の後、二人で合意にいたった事、「Googleは、再度、イノベーションの余地はない、他が入り込む余地がないと思われているマーケットに、イノベーションの余地がある事を証明してくれたよね。」。僕らも、他が入り込む余地はないと思われる分野でも革新的なイノベーションがあれば入り込めるという事だね。そのイノベーションを生み出すのは容易くないが。「信じれる物一つにフォーカスしてがんばって行こう」って事になりました。

Googleが感じさせてくれた僕らの可能性、いつかものにしたいです。

Google Chrome

Giving Google Chrome A Spin. This Thing Moves Fast.

あまりにもGoogleブラウザーの記事、ブログが多いので、とうとうインストールしてしまった。感想、速い!本当に速い!。初めてFirefoxを使った時を思い出した。あの時もFirefoxがあまりにもIEに比べて速かったので乗り換えたのであるが、今、Chromeに乗り換えるか考案中。試すのは簡単なので、どうぞ。

ダウンロード:Google Chrome (BETA) for Windows

(*1) Linux バージョンはまだみたい。
(*2) Mac OSXバージョンは開発中みたいです。Platforms and Priorities: Mac Inside Google

24時間でウエブサービスを作る

去年の夏の始め、「個人ウエブ・サービスを作る」という目標を決めた。決めたにも関わらず、他の事に重点をおき結局何もやらずに去年の夏は終わった。やらなかった人で終わって良いのか?リベンジしなくて良いのか?

今日は2008年8月12日のランチタイム。妻と娘が日本から戻ってくる18日まで5日程ある。今やらなくていつやれるのであろうか?今夜から始めて、17日、日曜日の夜まで、上手く時間を使えば、24時間位時間を作れるだろう。今夜始める。

何を作るのか?

既にありふれたもので、新規性は全くないのであるが、ブックマーク・サービスを作る。理由、ブックマークサービスの一つであるdel.icio.usは、僕がもっとも頻繁に使う、ウエブサービスだから。一年以上前からマイ・バージョンのブックマーク・サービスを作ろうと思い続けてきたのも理由である。どうか、今あるサービスを模倣(クローン)しても意味ないじゃないかとはおっしゃらないで下さい。

プロジェクトのゴール?

マイ・バージョンのブックマークサービスを開発し、パブリックな場所に置く(ホスティングする)。二つの基本機能:1.ブックマークの管理。2.友人とのブックマークの共有。

なぜ24時間?

日本で働いているRuby Hacker、DominiekのBuilding a .com in 24 hoursに影響されて。

なぜ個人ウエブ・サービス?

個人サービスを作るコツのリンク先のブログエントリーに激しく影響を受けたので。

開発環境?

一年前はJava&Tomcatで行こうと考えていたが、ここ半年程、スクリプト言語に思いっきり惹かれている。今回はPythonとDjangoを中心に開発して行く。ツールはIDEから離れて、テキストエディタであるvim。

今夜、8月12日夜、プロジェクト開始

8月12日(火)

Software development Manager – 1時間30分

Unfuddleにアカウントを作成。レポジトリーにGitを選択。Gitは今話題のVersion Control Systemです。今日までGitを殆ど使った事がなかったので、チュートリアルから始めいきなり苦戦。UnfuddleのHelpにてUnfuddleがらみのところは解決。あと下記のリンクが役にたった。

Gitに何かコミットするために、Djangoプロジェクト及びアプリケーションの元となる部分を作成した。そしてチェックイン。

Unfuddleを選んだ理由:200MBの無料ストレージ、かつプライベート用Gitレポジトリーを提供している所は他にあまりない事。ReadWriteWebでも紹介されていた事。

つまずいた点:gitを使う為にssh用にパブリック・キーを設定しなければいけないのだが、その辺りの理解が浅く時間をロスした。

今日中(8月12日)に、レンタルサーバーを借りるところと、ドメインを取得するところまでしたかったのだが、これ以上やっていると明日に響くので、一旦中止。

8月13日(水)

ドメイン登録 及び レンタルサーバー - 2時間

ドメインは評判が高い、Gandiで登録。登録自体は簡単だった。登録ドメイン名はyou29.com、日本語発音でユニークと発音する。ちょっと無理やりだが。税金込みで$15でした。僕の意見だがHelpが読み難い。フォントも小さいし。

レンタルサーバーは、slicehostで一番安い256sliceを借りた。DominiekのBuilding a .com in 24 hoursでも紹介されていたが、自分が知る限り一番安いVPSホスティングです。slicehostも評判が良いのが決め手。価格は$20/月でした。初回は3ヶ月分購入しなければならない。Linux DistroにはUbuntuを選択。ここの設定もスムーズ。

つまずいた点:取得したドメインとレンタルサーバーのIPアドレスをDNSに登録して結びつけなければならないのであるが、Gandi、slicehost共に、DNS Hostingを提供していて、僕は、slicehostで提供されているものを使用したかったのであるが、Gandiのものがデフォルトで有効になっていて、GandiのDNS HostingからslicehostのDNS Hostingに切り替える方法を見つけるのに1時間以上費やしたと思う。Gandiのヘルプが読みやすければ、、、、、

今は、Peets Coffeeからこれらの作業をしたのだが家に帰って、レンタルサーバーにApache、MySql、Git、Djangoなどの設定をしようと思う。

サーバーの設定もろもろ – 3時間

Apacheをインストールする前にユーザー作ったり、SSHの設定したりやる事いっぱい!おー。
UNIXシステム・アドミニストレーターのお仕事って大変なんですね。今日まで分からなかった。Linuxサーバーの設定が良い経験になっている。
MySQLのインストールはコマンド1発。
Apacheのインストールもコマンド1発。これでyou29.comにアクセスすると”It Works!”の文字が表示されます。
一応PHPも入れとこうかな?いつか使うかもしれないし。今のところ使用しないのでa2dismod php5 で無効にする。
次はEmailの設定:Riverse DNSの設定がDNSに反映されるまで時間がかかるので後回し。
Djangoのインストール。
次はGitの設定:git-coreのインストール、Public-Keyの設定、初めてのClone成功。
RDNSがアップデートされないので、Emailの設定は明日以降。
slicehostはヘルプが充実している点がGREAT!

つまずいた点:サーバーの設定がこんなに大変だと思わなかった。Linux回りの知識をもっと鍛えないと!

サーバーの設定に飽きて来たので、ロゴを作ってみた。-> LOGO

既に合計で6時間30分経過。24時間で出来るのか?まだコード書き始めてないし。

今日まで、Djangoを使ったアプリはローカルのコンピューターで開発用サーバーでしか動かした事がないので、明日はコードを本格的に書き始める前に、アプリケーションのディプロイ方法に付いて確認しないと。

8月14日(木)

開発環境及びサーバー環境設定(続き) – 1時間30分

  • mod_pythonのインストール、Linuxにインストールするのは初めてなのでテストコードも書く。確認完了。
  • メール・サーバー (postfix)のインストール。その前に、DNSの設定。ヘルプを読みながら何とかこなす。オー、自分のホストから
  • メール・サーバのセッティング一つとっても、アドミニストレーターの仕事って結構難しいんだなー!
  • メール・サーバー・ホスティングする場合はブラック・リストに載らないようきっちりセキュリティの設定をする必要がある。

レンタル・サーバーの設定はこれで大体完了。初めてなので、ちょっと苦労したが、良い勉強になった。システム・アドミニストレーターの皆様、お疲れ様です。皆さんの凄さが分かりました。

コーディング – 2時間30分

  • 作業をしている間にDjangoのBetaがリリースされた。昨日、インストールしたばかりだが、Betaにアップグレード
  • モデル(ORM)の定義
  • MySQLインストールしっぱなしで設定がデフォルトのままだった。又設定だ。ウエブ・アプリのホスティングってサーバーの設定の仕事が多いのね。見積もりが甘かった。
  • アプリケーションをディプロイする為のsetup.pyを書く。Python初心者なので、全て調べながら書かなければならず、時間がかかる。何とかコマンド一つでアプリをディプロイできるようになった。
  • Django Adminを使用する為の定義を書く。
  • ホームページをDjangoから出力されるように書き換える。
  • 開発環境でテスト後、サーバーにディプロイしてみる。とりあえず、Mainページ、Django提供のアドミンページは動いた。

既に合計で10時間30分経過、ちょっと時間が足りないような。今のところ、モチベーションだけはある。明日は、ユーザー・レジストレーション・ページ、ブックマーク登録ページ、ユーザー用ブックマーク表示ページなどをViewとテンプレートを書く予定。

8月15日(金)

コーディング – 4時間

  • 昨日の作業の確認
  • Viewとテンプレート
  • CSS書いていたら時間を浪費した。

今現在、合計で14時間30分。残り、9時間30分。出来るのか?

8月16日(土)

コーディング – 8時間30分

  • 今日もCSS書いていたら時間を浪費した。
  • メイン・ページのデザインなど
  • ユーザー登録機能
  • ブックマーク登録機能
  • ユーザー用ブックマークページのデザイン+CSS
  • 進捗があまりないのに、時間は過ぎる。。。。

UIのデザイン及びCSSは苦手なのだが、そこに時間を取られて前に中々進めない。

今現在、合計で23時間。残り1時間。明日一日あるので、どこまで出きるのかな?予定通りにはいかなさそう。最低限の部分はがんばって作ろう。

8月17日(日)

コーディング – 7時間30分

  • まずはコードがなくなると困るので、Gitでチェックイン。Gitはまだまだ使いこなせていない。
  • UIの続き。苦手な部分に時間がかかる。
  • 今まで作った分を試しにサーバーにディプロイしてみる。”しかし”まずは、スタティック・ファイルをインストールするためのPythonのsetup.pyを書いたのだが、書き方が分からず1時間ロス。そして、ローカルのマシーンのApache + mod_python環境にディプロイしたのだが、また動かない。開発用Pythonウエブ・サーバーでは動いていたのに。。。ネーム・スペースの問題でした。そして、また時間のロス。そして、プロダクション・サーバーにディプロイ、今度はイメージが表示されない。環境設定の問題のようだ。これでOKかなと思って、一通り動くか試してみるが、いきなりログインできない。またバグFixだ。** Djangoで開発している人は結構いるようで、解決方法はインターネットですぐ見つかった。**
  • ブックマークの共有方法に付いて考える
  • 細かいバグの修正
  • 明日は寝坊できないので、後1時間程で今回のプロジェクトは終了しようと思う。
  • 今日2度目のディプロイをこれからしよう。
  • 今まで苦労した甲斐あってディプロイはスムーズ。Gitを使ってコードを全てUnfuddle上のGitリポジトリーにチェックイン、そして、サーバー側から全ての変更をGitリポジトリからPULL(コマンド名)して、そしてインストールスクリプトを走らせるだけ。多分、Apacheを再起動しなければならない修正は加えていないが、念のため、再起動。リリース完了。
  • アカウントを作って、テストしてみた。機能は少ないが一応動いている。
  • これで、今回のプロジェクトは終了とする。

まとめ

今回初めてウエブ・アプリと言えるもの(<-???)を、個人サービスとして作った。組織の中でのウエブ開発とは違って一歩踏み出せたと思う。作業に付いて:サーバーの設定にかなりの時間を割かれた。システム・アドミニストレーターの人達の大変さを、少しだけ垣間見れた。開発作業では、苦手なユーザーインターフェースのデザイン及びCSSにかなりの時間を割いてしまった。もう少し効率的にCSSを書けるようになるために、日々鍛錬が必要だな。今回は、時間がなかったのでJavaScriptの使用は控えた、そこでハマッテ前に進めないことが目に見えていたから。開発言語に選んだPythonに付いて、一ヶ月程前から始めたのだが、シンタックスを覚えてなくて苦労したが、特別なコードを書くような事もなかったので、なんとかなった。フレームワークに選んだ、Djangoに付いて、かなりの部分をフレームワークが行ってくれるので、開発するのが楽です。達成度に付いて、当初考えていた、タグ・クラウドとか、友達機能とか、RSSフィードとかまで実装する時間がなかった。最低限の機能しか実装できなかった。時間を見つけてコツコツアップグレードしていきたい。一時間作業したらリリース(ディプロイ)みたいな、アジャイルな開発を実践して行きたい。

トータルの開発時間: 24時間 + 6時間30分(オーバータイム) -> 30時間30分

ウエブサービスへのリンク you29.com

Hidekiのブックマーク: Hideki’s Bookmarks

you29は日本語読みで”ユニーク”と発音します。音の通りいつかは”Unique(ユニーク)”なサービスを目指します。今のところは、ぜんぜんユニークではないですが。

最後に、機能的にまだまだなので、使って下さいとは言えませんが、それでも使ってくださる人がいたら幸いです。

おしまい

Where the Hell is Matt? (2008)

友人のFirendFeedから、新しいMattのダンスビデオがYouTubeにアップデートされているという情報が流れて来た。僕は彼の前作、前々作のダンス・ビデオも好きなので、すぐに再生ボタンを押した。2回目を再生中、彼のダンス・ビデオを見ると、なぜかよい気持ちにいつの間にかなっている事に気付いた。Mattや一緒に踊っている人達が笑顔でダンスしているからなのか?それとも、音楽の選曲がよいからなのか?よくわからないが、僕の心を気持ちよくさせてくれる。日本のシーンも出てくるのだが、そこで一緒に踊っている女性達も笑顔で楽しそうだ。日本の新聞記事を読んでいると、日本の閉塞感が伝わってくるのだが、そんな事無く、若者たちは弾けていて、人生をエンジョイしているのでは?数秒のビデオからは判断できないのであるが。インドの女性達とインド風に踊っているシーンは笑える。僕は何回も再生してみています。2005年版、2006年版ともにかなりの回数を見ています。多分、皆さんも気に入ると思うのでぜひ見て下さい。よい気持ちになれると思います。

追記:もう一度見て思った事:20代半に世界にあこがれて、自分の中で旅行ブームがあったのだが、世界の色んな人々と景色を見ていると、その時の気持ちがよみがえって来る。

Where The Hell is Matt?

翻訳: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を参照して下さい。

The search is a portal to the web applications!

I used to use MapQuest mainly for internet Map application. Main reason was I have thought MapQuest’s Driving Direction’s result is better than Google Map and Yahoo! Map. I just realized I am using Google Map instead of MapQuest and this days I am rarely use MapQuest. Why? My consideration ended up that Google Map is well integrated with Google Search. I used to visit Map site, then typed address to find the map. This days, I types address in the search textbox of browser’s toolbar, top of search results is always the link to the Map. Search and Map application are well integrated, so it reduced total time to reach the map. It made my habit changed.

The search is a portal not only to the web but also to the web applications!

Google Street View

去年(2007年)の秋、マサチューセッツ州からカリフォルニアに引っ越して来た時には、まだ前に住んでいた辺りはGoogle Street Viewにはカバーされていなかった。いまだに時々マサチューセッツ州のMapを見るのであるが、今日見たら前住んでいた家の辺りがGoogle Street Viewにカバーされていた。凄く懐かしい気持ちになった。寒いけどまたマサチューセッツに帰ろうかなー。


家の窓から毎日のように眺めていたグランド

Social Network Services(SNS)….

今日、Flockを試してみた。FlockとはFirfoxを拡張した、ソーシャル・ネットワークブラウザーです。色々なサービスが良い具合に統合されていて、面白い。ここまでは、楽しいなとまだ思っていた。次に、ちょと前に登録したMyBlogLogに行った。いつの間にか、色々なサービスとくっついて、それらのサービスからデータを持ってきて、色々な情報を表示するようになっていた。要するに、MyBlogLogはソーシャル・ネットワーク化されていた。ここで、最近急激に色々なサービスがソーシャル・ネットワーク化されている事にびびりはじめた。さらに昨日のニュースでFacebookの23歳か24歳のファウンダーがお金持ちリストベスト10入りしたんだった。ついでに、GoogleのEVPがFacebookにCOOとして入社した話も出ていた。そういえば年初に、どこかのニュースで今ネットで重要なものは2つあると言っていた。一つは検索。もう一つはソーシャル・ネットワーク。ソーシャル・ネットワーク化の勢いが凄すぎて、今日は、ちょっとたじろいてしまった。次は何がソーシャル・ネットワーク化されるのかな?ちょっと波にのれてないような。。。。。

Blogged with the Flock Browser

GOはてな!

僕は、はてなが好きだし、嫌いでもある。はてなって会社は、僕にとって、理想的な会社であり、反理想的な会社でもある。

好きな点&理想的な点:外から見ていて、楽しそうにウエブ・サービスを開発し、さらにコミュニティー(はてな村)を作る事に成功し、かつ利益もちゃんと出している事。はてな(近藤社長)は、僕の夢を既に実現している。嫌いな点&反理想的な点:はてなのサービスは基本的にアメリカに既にあるウエブ・サービスの模倣である事。はてなダイアリーって、BloggerとかSixApartなどのブログ・サービスの模倣ですよえね?はてなダイアリーの特徴である、自動的にリンクを張る機能はTwikiからのコピーですよね?はてなブックマークってdel.icio.usの模倣ですよね?僕に独自の物を作り出せるかって言われたら、作れないので、これ以上はつこっみません。

嫌いな部分に付いて考えてみた。一般的に日本人(僕も含めて)はゼロから何か作りだすのは、苦手だが、既にあるものを改良するのは得意である。トヨタだって、ホンダだって車を発明したわけではないが、車の改良、車の生産方法の改良により、世界をリードする自動車メーカーである。キャノンだって、コピーをとる事を「ゼロックスする」というアメリカで、No1のマーケットシェアを誇っている。だから模倣するのは悪い事じゃない。成功のための手段である。今の日本のウエブサービスは、日本のマーケットで受けるように手をかけてローカライズする事で満足しているように見える。さらにもっと改良を加えて、はてブやはてなダイアリーを世界に逆輸出してほしい。

日本では外資系ソフトウエア会社、アメリカでは現地のソフトウエア会社で働いてきた自分としては、「日本発のソフトウエア(サービス)」という標語がいつか現実になってほしいと思っている。自分が知る限りで日本発のソフトウエアはRubyだけです。はてなには、京都に移っても日本だけでなく、世界を目指してがんばってほしい。

はてな京都移転に関して、ネガティブなコメントも多いようですが、はてなのアメリカでのチャレンジは、経験という面ではむだではないと思うし、アメリカからの撤退を速い段階(傷口が広がる前)で決定した事も良いと思う。大体、上場企業ではないのだから好きな事をやって良いと思う。これからも変な企業を貫いてほしい。

GOはてな!