2012年4月30日月曜日

JPMorganからグリーへ

新卒で入社して五年間働いたJPモルガン証券を退職して、今月からグリーでSNSの開発に携わることになりました。外資系証券会社のエンジニアからインターネット企業への転職という珍しい転職例なののですが、どのような考えで転職に至ったのか公開できる範囲でまとめました。一番の理由は、世界中の人々の生活を変えつつあるSNSの世界に関わりたかったからです。

まず、JPモルガン証券を退職した理由ですが、従業員のレベルは本当に高く世界中からとびっきり優秀な人達が集まった素晴らしい職場でした。僕は債券システム部という部署にいたのですが、東京オフィスでさえチームメンバーのほとんどが外国人で、毎日のように世界中(ニューヨーク、ロンドン、シンガポール、香港、ムンバイなど)のメンバーと協力して業務を進めていたので国際感覚はかなり身につきましたし、証券業務のという複雑で専門性の高い知識を身に付けることもできました。勿論、システム開発や運用のスキルも身につきました。

ただ、証券会社ということもありエンジニアが主役ではない点や、大手金融機関ということでコンプライアンスが厳しく社内の手続きが猥雑という点はありました。なので、ここ数年間でFacebookやTwitterを始めとする世界を変えるほどのインパクを持つ新しいWebサービスがどんどん出てきて、Facebookの「The Hacker Way」に象徴されるようなエンジニアが先頭に立って自由にサービスを作り上げていくインターネット業界には強く憧れていました。

数あるインターネット企業の中からグリーを選んだ理由は、SNSに対する興味、エンジニアを重視するカルチャー、積極的な海外展開の三点です。

まず、SNSに対する興味ですが、僕はFacebookのヘビーユーザです。最近はSNSを利用することによって自分のコニュニケーションのスタイルが変わり、時間や場所を越えて効率的にコミュニケーションがとれるようになりました。最近では友達と連絡を取るときにはメールではなくFacebookメッセンジャーで話すことが多いですし、人と知り合うときにも携帯番号などではなくFacebookで友達申請し合うようになっています。グリーのSNSはまだFacebookほど洗練されたものではないかもしれませんが、ゲームとの連携や半匿名性のような特徴を利用してFacebookとはまた違うタイプの面白いプラットフォームになる可能性があると思ってます。

次にエンジニアを重視するカルチャーです。転職にあたって他社ともお話をしたのですが、私が検討した会社の中ではグリーが一番エンジニア主導の会社だというイメージを持ちました。社長が自ら作って始めたSNSサービスが会社の始まりですし、創業時のキープレーヤーの多くがエンジニア出身という点が大きく影響しているからだと思います。会社によってはエンジニアは他の人のアイデアを実現するためのリソースとしての位置づけという印象をもった所もありましたので、そこは大きな魅力でした。

最後に、積極的な海外展開ですが、グリーは世界市場をを狙える日本企業という点でもとても魅力的でした。今までは「世界展開している外資系大企業の東京支社」で働いていたので、意思決定権をもっているマネージャーがロンドンにいたりして、予算や技術的な枠組みがすべて海の向こうで決まった後に僕らがそれに合わせてプロジェクトにアサインされれローカライズするような形でした。なので、程よい規模で世界展開をすべく急激に成長している企業で働けるという点は大きな魅力でした。JPモルガンで海外のエンジニアチームと協力してプロジェクトを進める能力はかなり身についたと思うので、今度は日本から世界へという部分でその能力を活かせたら嬉しいです。

そんな感じで4月頭に入社して丁度一ヶ月経ちますが、基本的にはイメージしていた通りの会社で順調にやってます。特に、前職がマネジメントが強い会社だったこともあってか現場主導の環境にとても心地よさを感じていますし、カルチャーの違い(全然違うよ!)なども楽しめています。その辺りを含めて、まだブログに書きたい事はいくつかありますが、今回はこの辺で。

2012年4月22日日曜日

Graph APIとGAEでお遊びアプリ

実は先月暇だったので、WebアプリケーションとKVS(Key Value Store)のお勉強をすべく、FacebookのAPIとGAE(Google App Engine) Pythonを使ってFacebookのフィードや友達、所属するグループの簡単な統計情報を表示する小さなアプリケーションを作りました。まぁしょぼいアプリですが、ここでちょろっと紹介します。

http://pei-fbstats.appspot.com/

基本的にはfacebookのGraph APIを使って友達の性別や所属、コメントやLikeの数などを集計しているだけのアプリです。遥か昔に忘れたHTMLの書き方とか、GAEの使い方や初めて書くPythonやjQueryやKVS(結局使わなかったけど)の使い方とかを覚えながら、のべ二週間くらいかけて作りました。Feedのコメント数とかが微妙に上手く取れていないことがあるような気もしたりするので、お遊びの参考程度だと思っててきとーに使ってください。ユニットテストすら書いていないので…。気が向いたらちゃんと確認します。

なんか問題があっても責任はとりませんがw、当初のKVSのお勉強をするという目標とは裏腹に、実はデータは全くKVSにストアしていないのでデータ集めてるとかはないです(KVSは使ってみたし勉強はちゃんとしたけどね!)。でも、毎回Graph API叩くのはさすがにパフォーマンス的にどうかと思うので、cache目的で使った方がいいだろうなぁとは思ってます。まぁでもその目的ならBigtableではなくmemcachedになるか…。でも、たぶん転職直後で忙しくて触ってる暇はもうないですが。

以下、使ってるサービスとかライブラリの説明です。たぶんWebプログラミングに慣れてるひとからするとアホみたいな話でしょうが。僕が5-6年前に大学でやっていた頃と比べると、特にクラウドサービスとかJavascriptのライブラリの充実ぶりが半端無くて、本当に簡単にWebサービスが作れる時代になったんだなぁと実感しました。

GAE
サーバ借りたりとか面倒だし、勝手にスケールしてくれるし(そんなに使う人いないと思うけど)、僕みたいな怠惰な人間には最高のプラットフォームです。余談ですが、GAEではurllib2.urlopenは使えなくてgoogleの用意したurlfetchっていうライブラリを使わないといけないみたいです。socketが使えないのが理由みたい。軽くハマりました。詳しくはここで(The URL Fetch Python API)。

Facebook Graph API
言わずと知れたfacebookのAPIです。リクエストの数が多い時には複数のリクエストをまとめてPOSTできるbatch機能とかもあったりして便利でした。けっこー、レスポンスに時間がかかったりするのでtimeoutとかpagingとかのパラメーターを上手く調整する必要があります。でかいデータにアクセスしようとすると、時間かかったりレスポンスがなかったりするのはこいつのせいです。(嘘です。ぼくが怠惰でエラーハンドリングとかcacheとかしてないせいです。)

jQuery
Webに慣れてる人は何を今更って感じでしょうが、奇跡のライブラリですねこれは。恥ずかしながら今回はじめて使ったのですが、非同期の処理が本当に簡単にできてしまってjavascriptの敷居を一気に下げるツールです。6-7年前に自分でオブジェクト作ってブラウザごとに分岐したりしてAjaxの処理を作っていたのが懐かしい(というか馬鹿みたい)。

simplejson
Graph APIはJSONでデータを返してきますし、このアプリも基本的にサーバ側はJSONでデータを返すだけで、クライアント側がサーバから返ってきたデータを可視化しています。実はJSON形式のデータって今まで使ったことなかったんですが(証券会社勤務だったのでJavaでXMLみたいな堅いメッセージングばっかり)、すごくシンプルなデータ構造ですし、このライブラリを使ったら超簡単に扱えました。pythonの配列や辞書形式のデータとJSONの文法がほとんど同じだったなのですぐに慣れました。python2.6以降ではデフォルトで含まれているみたいですが、GAEがサポートしているpython2.5に含まれていないので自分で落としてきました。このチュートリアルが分かり易かった。

gae-sessions
後はwebappというGAEビルトインのフレームワークにはSession管理機能が含まれていないためgae-sessionsというセッション管理ライブラリを利用しました。たしかmemcachedを使ってるライブラリだったような。

Google Graph Tools
グラフはGoogleのAPIを利用しました。javascriptのオブジェクトにデータ突っ込むと勝手に綺麗なグラフを作ってくれます。pie chartとbar chartしか使わなかったけど本当はもっと色々と細かいことできるみたいです。

Graph API Explore
Graph APIで遊ぶなら必須ツールです。APIがどんなメッセージを返してくるのか簡単にチェックすることができます。

Favicon Generator
faviconはこれでテキトーに作りました。

git
Dropboxをレポジトリにしてgitで管理しました。一度、リファクタリングしたらGitHubに乗せてみようかな。


今後追加してもいいかなぁと思っているもの
  • キャッシュ。毎回時間かかり過ぎだから。
  • 人の名前をクにその人のFBページのリンクをつける。(Google Chart Toolsで簡単にできそう)
  • 自分と一緒にタグ付けされている人のランキング
  • 友達やグループメンバーのフィルタリングツール(友達を所属とか年齢や性別みたいな属性で絞り込むような機能。絞り込み後にメッセージ一斉送信とかできたら更に使えるかなみたいな。)

2012年3月12日月曜日

昔のブログ「外資系投資銀行を選んだ理由(2006年03月20日)」

最近、大学の研究室のサーバで眠っていた僕の修士課程時代のブログを見つけたので救出して読んでみました。2005年〜2007年くらいまで書いていたのですが、特に就職活動やキャリアの考えたかに関して興味をもって貰えそうなエントリーがいくつか出てきたので、基本的にはそのまま転載する形でいくつか紹介していきたいと思っています。

僕は修士課程在籍中の2005年3月のにJPモルガン証券のシステム部門に内定して2007年の4月から新入社員として入社したのですが、以下のエントリーはその時にどうして僕が外資系投資銀行のシステム部門という特殊な職を選んだのかを説明したものです。

6年経った今ではソフトウェアエンジニアの争奪戦が起こっており、高度な知識や技術をもったエンジニアの価値や待遇がどんどん高まっているという点では、この時の僕の考えはかなり的を得ていたと自分でも思っています。このエントリーで述べている僕のITコンサルやSIerに関する見方はちょっとステレオタイプな部分もあるかもしれませんが、今でも自分のキャリアに対する考えはこの時と殆ど変わっていません。6年前のひよっこ時代にも、それなりに物事を考えていたんだなぁと昔の自分にちょっと感心 :)



2006年03月20日
外資系投資銀行を選んだ理由

初のトラックバックです。以下のブログを読んで思うところがあったので。
「Life is beautiful: ソフトウェアの仕様書は料理のレシピに似ている」
要約すると、日本のシステム開発は「上流→下流」とゼネコンみたいに階層化されていて、プログラムもろくに書かない上流コンサルタントの設計を下請けの下流プログラマが仕様書どおりにコーディングするという構造になっている。そんなの効率悪いし、品質のよいソフトウェアはできないよという話。
この問題は、就職活動をするにあたってソフトウェア・エンジニアとしてガリガリと開発ができる職種を求めていた僕が、外資系投資銀行のテクノロジー部を選んだ大きな理由の一つ。
日本のシステム開発は上記のような階層構造になっているため、価値の高いことをしようと思うと、ITコンサルタントという職を選ぶしかない。IBM、アクセンチュア、野村総研とかのね。こういう企業では入社しばらくはプログラマとして下働きをして、その後に「泥臭いコーディングなんてしないコンサルタント」としてステップアップするらしい。その後は、マネージメントやお客さんから仕事をとってくる営業活動がメイン。技術重視では出世できない。実装を行う下請けの会社では、プログラムを書かない人達が作ったガチガチの設計書を元に、就職して初めてプログラムを書くような経験の少ない人達がコーディングを行う。「プログラマ=初心者」という感じで、プログラマの地位は低い。階層構造の上の方からしっかりと利抜きされて仕事が回ってくるため給料も低い。
この階層構造の中での仕事を回避するために、少数で効率の良い開発を行っている企業をターゲットにしてみた。初めに考えたのは外資系のソフトウェアベンダーやインターネット企業。ソフトウェアベンダーとしてはマイクロソフトやオラクルが挙げられるけど、開発の拠点はアメリカで、日本の支店はそのローカライズや顧客サポート、営業が大半を占める。やっぱり一番魅力的な会社はGoogleなのだが、さすがに敷居が高すぎるし、どうしようかなぁと悩んでいたときに出会ったのが外資系投資銀行のテクノロジー部門。
基本丸投げの日系金融機関と違って、外資系投資銀行ではITをとても重視している。開発は少数のエンジニア達により殆ど自社で行う。エンジニアには金融工学などの数学的センスも求められるみたいで、専門性が高い。ここで頑張ればコンピューター・サイエンスと金融数学を武器にできると思って、この業界に決めた。海外のエンジニアさん達との共同開発や、成果を重視する評価精度も魅力的だった。日本の会社って若いうちは安い給料で奉公って感じだから。まぁ、エンジニアが主役となる会社ではないっていうのがネックなんだけどね。
採用人数はとても少なく、面接は英語ばかりだし、いきなりプログラムを書かされたりと大変だったが、運良く内定を頂くことができた。という訳で外資系投資銀行のテクノロジー部門に就職する事になった。

2012年2月29日水曜日

旅券統計で遊んでみた

近いうちにハワイ旅行に行こうと思っているのですが、パスポートの残存期間が半年を割っているのでそろそろ更新したほうがよいかと思い調べてみると、10年券の発行には1万6千円、5年券の発行には1万1千円もかかるではないですか。仮に裏に外務省の天下り機関とかがいたらとしたらどれくらいウハウハなんだよ勝手に妄想していると、なんかムシャクシャしてきたので数字を調べてみました。

外務省の統計によりますと、平成23年のパスポート発行数は5年で1,543,554、10年で2,417,828の合計3,961,382だそうです。以下のように計算してみると、一年で550億円以上の収入が入っていることが分かります。あんな小さい冊子にICチップを埋め込んだ程度のものなので、作成には1000円もかからないでしょうし、事務手続きも簡単だと思うのですが…

1,543,554 x 11,000円 + 2,417,828 x 16,000円 = 55,664,342,000円

後、てきとーに数字を眺めていると以下の事にも気づきました。

  • 若い世代のシーズナリティが強い。
    • 特に19才以下は8月の夏休みと3月の春休み期間に発行が集中しており、その二ヶ月で一年の発行数の25%を超えています。
  • 20才を超えると年齢と発行数が逆相関になっている。
    • 面倒くさくてちゃんと調べてないけど、Wikipediaの年齢別人口のグラフを眺めたところ、20代よりは30代、40代、50代の方が人口が多そうなのに発行数が減っていっています。やっぱ若者のほうが海外旅行に行きたがるのですかね。
  • 都市部の発行数が多い
    • 人口に応じて発行率(発行数 / 人口)が上がる。
      • 上位は東京(4.80%)、神奈川(4.22%)、千葉(3.65)
      • 下位は青森(1.21%)、秋田(1.41%)、高知(1.66%)
    • 以下、縦軸を発行率、横軸を人口として各都道府県をプロットした図です。水色のラインはただの線形回帰。なんとなくイメージが掴めると思います。

で、結局550億円って一体どこに行くのでしょうか??

参考
外務省旅券統計
Wikipedia 日本の人口統計
Wikipedia 都道府県の人口一覧

2012年2月20日月曜日

Sitting is Killing You

昔見つけたインフォグラフィックス。僕は昔からかなりの腰痛持ちだったのですが、これの通りに135度くらい傾けて体重をしっかり背中に預けて、足を伸ばしたりしながらプラプラしてると、腰痛が和らぐことに気づきました。お勧めはスチールケース社のリープチェア。

Sitting is Killing You
Via: Medical Billing And Coding

2012年2月19日日曜日

読書日記「仮想世界錬金術 モバイルソーシャルアプリに見る現代ディジタルコンテンツ革命」

今、破竹の勢いでビジネスが拡大しているモバイルソーシャルゲームについて勉強してみたいと思って読んでみました。僕もモバイルソーシャルゲームは「破壊的イノベーション」の典型例だと思っていて、最近はとても注目しています。グリーやDeNAの好調な業績が世間を驚かせていますが、国内のソーシャルゲーム市場は2012年度には3400億円を突破すると予想されているようです。(矢野経済研究所:ソーシャルゲーム市場に関する調査結果2011より)また、同時に海外市場への進出も急速に進めています。本書ではソーシャルゲームビジネスがいかに拡大してきたか、ソーシャルゲームの基本原理、またそのマーケットについてを実例に基づいて説明しています。

僕が一番面白いと感じたのは、モバイルソーシャルゲームはひたすらEnterを押し続けるような単純なゲームに見えながらも、裏側では以下のような技術やノウハウが凝縮された、かなり高度なサービスだということです。
  • 限られた機能、コンテンツ、UIでいかにユーザを楽しませるか(ゲームニクス理論、エクスペクトロジー、時間の使わせ方など)
  • どうユーザ間のコミュニケーションを楽しませるか
  • データマイニングに基づくチューニング
  • フレームワークを利用した少人数、短期間での開発
  • クラウドサービスや並列処理を利用した負荷分散

個人的には、これからゲームビジネスはどんどんパッケージ型から課金型へビシネスモデルが変換していくと予測しています。据え置き型のゲームも初期の価格設定を低く抑えて、コンテンツやアイテムなどで課金していくのが主流になっていく気がします。正直、僕自身がモバイルソーシャルゲーム(怪盗ロワイヤルとかドリランド)をやった限りでは、システムが単調すぎてのめり込むほど面白いとは思えなかったんだけれども、おそらく今後はスマートフォン向けの新しいゲームがどんどん出てきて、もっとリッチなコンテンツを求めるユーザ層も獲得していくだろうと思っています。メインフレームがオープン系のワークステーションに置き換えていったようにね。海外進出もどんどん進められているようなので、日本のIT企業が海外の市場でどれだけ戦えるのか楽しみですね。

2012年2月8日水曜日

読書日記「企業のファイナンス ベンチャーにとって一番大切なこと」

ちょっと起業して一発当ててやろうと思い(嘘)、友達に薦められた、「企業のファイナンス ベンチャーにとって一番大切なこと」というベンチャー企業のファイナンスの本を呼んで見ました。磯崎哲也さんというベンチャービジネスやファイナンスについて書かれたisologueというブログで有名な方です。

この本は、実際に自分が起業した時のイメージを持つために書かれており、起業の流れやファイナンスの仕組み、上場やバイアウトのプロセス、実行時にに気をつけたほうが良いことなどを易しく筆者の経験を交えながら説明してあります。

かなり幅広い事を説明しているので詳細まで紹介することはできませんが、事業計画の作り方、ストック・オプションや種類株式や投資家(VCなど)との交渉の仕方の説明まで含めた資本政策の方法、バイアウトや上場によりどうキャピタルゲインが得られるのかなどまで説明してあります。僕は証券会社に5年間ほど勤務しているので基本的なファイナンスの知識はあるのですが、上場時に何が必要になるかや、種類株式を利用して如何にすべてのステークホルダーの利益を損ねないように増資を行うかなどの説明はとても興味深かったです。

また、日本はベンチャーの市場規模が小さく、「ベンチャーに冷たい」と言われがちですが、実際にはそうではなく足りていないのはアニマルスピリッツをもったイケてる創業者や、それをサポートする仕組みだというのが著者の意見です。

シリコンバレーみたいに次から次へと競争力もスピードもあるスタートアップが湧いて出てくる環境と比べればライバルが少ないですし、サポートしてくれる人は資金政策さえ上手く行けば、競争の少ない分だけ上手く行く可能性が高いのかもしれませんね。

2012年2月5日日曜日

MacPortを使ってみた

Macを4年間近く使っているエンジニアのくせに、開発は会社のWindowsマシンでしか行ったことがなかったので、恥ずかしながらMacPortを使ったことありませんでした。

ちょっとPython2.5.*をインストールしたかったので試して見ました。

とりあえずこんな感じでパッケージを探します。そしたらpython25というパッケージが見つかりました。

sudo port search python
.....
python25 @2.5.6 (lang)
    An interpreted, object-oriented programming language
.....

なのでこうやってインストール。

sudo port install python25

で、ここにパッケージがダウンロードされる。

ls  /Applications/MacPorts/MacPython\ 2.5/
Build Applet.app IDLE.app  Python Launcher.app
ls /opt/local/bin/ | grep python
python-config2.5
python2.5
python2.5-config
pythonw2.5


とりあえず、ここのページにリストアップしてあるコマンドさえ覚えておけば、ひと通りのパッケージ管理は簡単にできそう。


でも、実はここに初めからインストールされているのでPathに追加するだけで良かったというオチ。
/System/Library/Frameworks/Python.framework/Versions/2.5/bin

2012年2月4日土曜日

新しいMacのセットアップメモ

新しいMacを買ったので、インストールしたソフトとかをメモ。

General Software

  • Evernote
  • Dropbox
  • Kindle
  • Google Japanese Input
  • Stufflt Expander
  • Skitch
  • Libre Office
  • weblio (chrome plugin)
  • Google 日本語入力


Development Environment
  • git
  • eclipse 3.7 indigo
  • google SDK plugin
  • EGIT plugin (import project from git repository in dropbox)
  • XCode
  • MacPort
  • nkf
  • Google App Engine SDK for Python
  • Cocoa Emacs
  • MacVim


System preferences
  • Sharing -> Web Sharing (you can share your site in /Users/$USER/Sites)
  • Keyboard -> Keyboard -> disable caps
  • Trackpad -> change track speed

2012年1月28日土曜日

読書日記「エンジニアとしての生き方」

著者のLife is Beutifulというブログからの記事と、雑誌などのコラムを編集した、主にエンジニアのキャリアについて述べられた本です。

実は私は学生の頃から中島さんのブログが大好きで、キャリアの意思決定などにかなりの影響を受けてきました。新卒で今の会社に入社したのも、中島さんのブログで英語の重要さや自分でブログラムを書くことの重要さを認識したという点がかなり大きな理由です。外資系の証券会社は外注ではなく殆ど社内で開発を行いますので。

彼のテクノロジーに対する真摯さやモチベーションの高さに感服すると同時に、以下のような彼の主張に強く共感し、影響されてきました。

  • どんなに優秀なエンジニアでも、決してプログラムを自分自身で書かずに良い詳細仕様を作ることは出来ない(プログラミングは知的な仕事であり、ITゼネコンの下請け構造では良いソフトウェアは作れない)
  • 会社人間ではなく真に価値のある人材になろう(社内だけではなく業界全体または社会全体で価値のある人材を目指すべきである)
  • 知的労働者には「組織を移る力がある」(自分のキャリアプランと日々の仕事をシンクロさせる)
  • 技術者にも必要な「儲ける決意」(技術者にも儲ける意識やビジネスセンスは重要)
  • 英語はグローバル人材市場へのパスポート


でも、僕の心に一番刺さったのはこの文章ですね。( Software is Beautiful「第1回 一生の仕事を選ぶということ」より引用)
せっかく職に就くのであれば,給料とか社会的地位とかを基準にするのではなくて,自分が好きなことやりたいこととマッチした職を選ぼう,というのが私の人生論である。若いうちにいろいろなものに触れておき,自分が本当に何がしたいのか,何になら夢中になれるのかをできるだけ早いうちに見つけ出すことはその後の人生にとって大きなプラスとなる。そんな「天職」を得るための努力なら惜しむことはないし,けっして無駄にはならない。そうやって「好きなことをして生きていく」ための努力を続けている限り,(ほかの人にとっては)つらいことも苦痛ではなくなるし,楽しい人生がおくれる。一度しかない人生,思いっきり楽しもうぜ。
この本を読んで、自分の好奇心に忠実に、常に全力で情熱を注げるできるような仕事をして生きていきたいと改めて感じました。

2012年1月27日金曜日

JSONICを使ってみる

ちょっとJavaでJSON形式のデータを扱う必要があったので、JSONICというJSON Parserを利用して見ました。JavaのライブラリではJSON-libというのが定番らしいのだけれど、他に依存するライブラリがあったりして面倒そうだったので、とりあえず一番シンプルそうなJSONICを使いました。

僕はFacebookのGraph APIで返ってきたJSON形式のデータをJavaのオブジェクトとして取り込みたかっただけなので、decodeだけ利用しました。使い方はとても簡単で、JSONのフィールドと対応する変数とaccesserを持ったクラスを指定してやるだけ。

まず、Graph APIはユーザの情報を以下のような形で返してくれます。

{
  "id": "123456789", 
  "name": "Foo Bar", 
  "first_name": "Foo", 
  "last_name": "Bar", 
  .....
}

で、以下のようにidとnameの変数とアクセッサを持ったクラスを定義してやります。

public class FBUser {
   private String id;
   private String name;
 
   public FBUser(){ }

   public String getId() {
      return id;
   }

   public void setId(String id) {
      this.id = id;
   }

   public String getName() {
      return name;
   }

   public void setName(String name) {
      this.name = name;
   } 
}

そして、以下のようにJSONのデータとクラスの型を引数にしてdecodeを呼ぶと、勝手に個々のフィールドに値を入れてくれます。おそらく、リフレクションを使ってJSONのフィールド名からsetterの名前を推測しているのでしょう。例えばフィールドが'id'だったら'FBUser.class.getMethod("setId")'とかね。ちゃんとidとnameがログに出力されました。

String jsonFbUser = FBLoginUtil.getResponseFromURL(FBLoginUtil.getGraphApiUrl() + "me"  + "?access_token=" + accessToken);
final FBUser fbUser = JSON.decode(jsonFbUser, FBUser.class);  
log.info("id:" + fbUser.getId());
log.info("name:" + fbUser.getName());

このブログを書くよりは遥かに短い時間でオブジェクトとして取り込むとこまで出来てしまいました。オジサンの知らない間に世の中便利になってますな。賢い人達、いつもどうもありがとうございます。

2012年1月26日木曜日

gitを使ってみた

gitを使ってDropboxにレポジトリを作ってみた。ついでに、EGITをインストールしてEclipseからcommitとpushができるようにもしました。

最近、一人で開発を始めたのですが、ワークスペースが全部ローカルのMacに入っているので気持ち悪いと思い、Dropboxをレポジトリにしてgitを導入してみた。僕はsubversionしか使ったことないのですが最近の若者に流行りらしいのであえて。一番の違いは、serverで一元的に管理するsubversionとは対照的に、gitはすべてのコピーがマスタレポジトリのフルコピーを持っていて、ヒストリーの確認は勿論、コミットもできる分散レポジトリであるという点みたいですね。

とりあえず、Mac OS X 用のインストーラーがココにあるので、ダウンロードしてインストール。git help とコマンドを打ってみると、add/checkout/diff/commitなどsubversionで見慣れたコマンドが並んでいて一安心。

まず、user.name、user.emailをgit config コマンドで登録します。

git config --global user.name foo
git config --global user.email foo@bar.com

どうやらversion1.7.5からはレポジトリとワークスペースのディレクトリを別にする--separate-git-dirというオプションが追加されたようなのでDropboxだけでレポジトリを管理しようかとも思ったのですが、DropboxをマスタにしてLocalドライブを自分用にした方が分散レポジトリというgitの哲学に合ってるんじゃないかなぁと感じたのでそうしました。毎回マスタにPushするのはちょっと面倒かもしれないけど。


レポジトリを作るのはアホみたいに簡単で、Dropboxに適当なディレクトリを作って(e.g. $HOME/Dropbox/git_repos/MyProject.git)、そこにcdしてgit --bare init とコマンドを打つだけ。

僕はEclipseでGoogle App Engineのアプリケーションを書いているのでEGITというEclipseから使える管理ツールをインストールしました。subversionで言うsubclipseみたいなもので、ちょっと触ったところ使い方は殆ど同じなので、10分位でレポジトリ作ってcommitしてDropboxにpushするところまでできてしまいました。試しに、マスタレポジトリからgit clone で適当なディレクトリにコピーしてみたらちゃんとディレクトリ構造がコピーされました。Dropboxはディレクトリごとに他のユーザと共有とかできるはずなので、$HOME/Dropbox/git_repos/MyProject.git を他のユーザと共有すればマスタリポジトリの共有も出来ますね。

今回の作業では以下のページを参照しました。どうもありがとうございました。
Subversion ユーザーが Git を使ってみた (基本操作編)
Dropboxを利用してGitのプライベートリポジトリをつくる方法
git 1.7.5で追加されたオプションを使ってgit on Dropboxの運用を見直す
EGit/User Guide

2012年1月16日月曜日

読書日記「Web開発者のための 大規模サービス技術入門」

株式会社はてなの伊藤さん(現GREE)と田中さんという、Webに興味のある人なら名前くらいは聞いたことがあるだろう人達の書いた、「Web開発者のための 大規模サービス技術入門」というその名の通り大規模なWebサービスをどう運用していくかを説明している本です。理論的な説明だけではなく、実際にはてなで使われている運用方法などの「泥臭い」部分をかなり詳しく説明してくれているとても実践的な本でした。

この本を読んで、もし自分で大規模サービスを運用が必要になる時には絶対に自分でインフラは持たずにGoogle App Engineのようなクラウドサービスを使おうと思ってしまいました。さすがに自分でここまでする気にはならないですね…。

基本的にはパフォーマンスの問題はCPUかI/Oのどちらかがボトルネックになります。そういう時は単順にtopやsarでどちらの問題か切り分けます。どのプロセスがCPUをどれくらい使ってるかとかI/Oの待ち時間がどれくらいあるのかとかを確認すれば、だいたい目星はつくでしょう。

CPUがボトルネックの場合は以下のような解決方法があります。単純に計算量が足りないだけなので、比較的解決は簡単なようです。
  • サーバを増やして処理を分散させる。この場合はDBと違ってデータのレプリケーションなども必要無いので、比較的簡単にスケールする。
  • アルゴリズムを改善して計算量を減らす

I/O側はCPUのように、サーバの台数を増やすだけでは簡単にスケーリングできないので対応が難しいようですね。Googleが独自の分散ファイルシステムやデータベースを持っているのもそれが理由でしょう。対応の仕方としては以下の方法があるそうです。
  • できる限りキャッシュやメモリのヒット率を高めてディスクアクセスがないようにする。(メモリはディスクアクセスの10万倍以上高速)
  • プログラム変更でメモリの利用が減らせるならそうする。
  • 足りなければメモリを増やす。できないならデータを複数サーバに分散させる。
  • データベース側のスケーリングをする(最終手段)。マスタDB(書き込みを担当するDB)のスケールアウトはACIDが求められるため難しいが、テーブル毎やエントリー毎に別サーバにデータを分散させるようなトリッキーな事をすることもあるようです。TwitterもMySQLの分散とmemcachedで運用しているみたいですね。

RDBの分散やデータの圧縮の話はとても面白いと思いました。RDBのデータを分散するのにテーブル毎に別サーバに分散させたりするので(勿論できるだけ局所性を保つように分散する)、INNER JOINを使わずに複数回クエリを投げるプログラムを書いたりするらしいです。もはや、RDBではないですね。

他にも、データ圧縮をI/Oを減らすためだけとかに使ったりとか、データをページキャッシュにのせるためにアプリケーションで使われる大規模データを一度catしたりとか、面白いノウハウが載っていました。そういえば、僕のサポートしているシステムでもデータをキャッシュに入れるために、再起動するたびにウォームアップさせてるなぁなんて思いながら読みました。

後半のインフラ系の話の部分はまだ読めていないので、また後日にでも。ちらっと見た感じ、SSDを使った高速化とか面白そうだな。明日、Macbook Airが届く僕としては…

2012年1月7日土曜日

読書日記「Webを支える技術-HTTP、URI、HTML、そしてREST 」

ちょっとWeb系の技術の基本的な部分を勉強してみようと思って、「Webを支える技術」という本を読んで見ました。RESTfulな設計の大切さ、URIとHTTPの説明、ハイパーメディアフォーマットなどのWebに使われている基本技術の説明がメインで、最後に少しWebサービスの設計例が載っています。僕のような、コンピュータの基本的な知識はあって、勿論HTMLやJavascriptはある程度書いたことはあるけれども、体系的に勉強した経験がないような人間に丁度よい本でした。

本書ではRoy Fieldingが提唱したREST(Representational State Transfer)というWebのアーキテクチャースタイルを良しとしており、URI(リソース)、HTTP、ハイパーメディアフォーマットについて説明すると同時に、いかにそれらをRESTfulに利用するかについても言及しています。本書では、以下の6つの制約を合わせたアーキテクチャースタイルがRESTであり、実際のアプリケーションは必要に応じていくつかの制約を除外しながら実装すれば良いと述べています。

  1. クライアント/サーバ
  2. ステートレスサーバ
  3. キャッシュ
  4. 統一インターフェース
  5. 階層化システム
  6. コードオンデマンド

個人的には一番印象に残ったのはMethodの説明です。僕が学生時代にWebを少しかじった頃はちょうどSOAPが出てきた頃で、たしかSOAPで実装されたGoogleのWeb検索APIとかで遊んだ記憶があるのですが、今は完全にRESTに基づいてHTTPメソッドを使い分けるのが主流のようですね。5年前の僕がしていたPOSTだけですべての処理をこなすなんていう処理は完全なるアンチパターンのようですね。HTTPには以下の8つのMethodが用意されており、個々の役割は決まっているので用途に応じて使い分けるべきらしいです。
  • GET
  • POST
  • PUT
  • DELETE
  • HEAD
  • OPTIONS
  • TRACE
  • CONNECT

後はHTTP、URIやデータフォーマット(HTML、JSON、microformats、Atom)の説明や、通信プロトコル、ヘッダー、ステータスなどのリファレンス的な情報などの説明もあり、基本的な技術をおさらいするのにはとても便利でした。


2012年1月5日木曜日

ソーシャルゲームで遊んでみた

MobageやGREEなどのソーシャルゲームが流行っているようなので、どのようなものかと興味本位でちょっと遊んで見ました。とりあえず、以下にリストアップしたものをチョコチョコやってみました。

Mobage
怪盗ロワイヤル
忍者ロワイヤル
大熱狂プロ野球カード

GREE
FIFA
ドリランド
Gantz
クリノッペ

どれもゲームシステムはかなり似通っているという印象を受けました。どのゲームもガチャでカードを入手して、ミッション(クエスト)でレベルを上げたり、他のプレーヤーとバトルをするという楽しみ方ですね。で、ガチャとアイテムの課金で収益をあげると。これ、上手くやったらソーシャルゲームフレームワークみたいなものを作って、中身のコンテンツを差し替えるだけで色々なゲームが作れるようになってしまうのではないだろうか。ていうか、もうあるのかもね。少なくとも、コードの大部分は使いまわせるはず。

以下、キーワードの説明。

カード
「ガチャ」でカードを入手。無料ガチャと有料ガチャがあり、だいたい一回100円(ノーマル)か300円(レア)でガチャれる。各カードには攻撃力、防御力などのパラメータがある。基本的にはレアカードの方が強い。カードは合成して強くしたりもできる。

ミッション(クエスト)
基本的には「ミッションの実行」というボタンを押していると、カードを入手したり、レベルが上がったりする。たまにボスなどとのバトルになったりもする。実行するたびに行動ポイントを消費して、それがなくなると数時間回復を待つ、もしくはアイテムを使って回復できる。

バトル
他のプレイヤーとバトルができる。勝つと相手のアイテムを奪える。ボスバトルなどでは他のプレーヤーと協力して戦うこともできる。殆どのゲームではバトルは勝手にコンピュータが行う。バトルではチームメンバーの選択や配置などの戦略的な要素もそれなりにあるのだが、バトルの中身はスキップして結果だけを表示するゲームも多数あります。

アイテム
消費したパラメータを回復するアイテムとか、宝を守るアイテムとかがある。100円くらいで買える。

ゲームシステムがここまで似ていると、レアカードを強くしたりアイテムを集めたりというコレクション的な要素で差をつけるんでしょうね。後はユーザ間のコミュニケーションなどもアクセントになっていると思うのだけれども、そこまではやりこめませんでした。