2009年9月25日金曜日

スティーブ・ジョブズが目の前なう






2009/09/25: 帰宅したらきちんとした写真アップします。
2009/09/28: 写真アップしました。

■これまでのあらすじ
アメリカ旅行1日目
アメリカ旅行2日目〜3日目


■まずはGoogleへ
今日はCaltrainに乗ってシリコンバレーへ向かいます。お目当てはGoogleとAppleの本社!

Caltrainのサンフランシスコ駅へ到着。日本の駅と作りが全然違ったり、標準軌道(広軌?)だったり、全2階建ての客車をディーゼルの機関車が引っ張る構成だったり、そんな機関車がずらりと横一列に並んでいる姿が拝めたりと、鉄道マニアにはたまりませんよ。あ、私は鉄道マニアなんかじゃないんだからねっ?><

一路San Antonio駅へ。ここからVTAのバス40番に乗り換えて一路Googleへ移動。
駅で降りてまず感じたのが、空が広い!明るい!緑が鮮やかで綺麗!暖かい!家並みが美しい!まるで絵に描いた楽園のような風景です。なるほど、これはすごい。みんなシリコンバレーで起業したがるわけです。

Google到着。めっちゃめっちゃ広い!!><
雰囲気としては途中Palo Alto駅すぐそばにあるスタンフォード大学のキャンパスとそっくりで、全然「会社」って感じがしません。緑がたくさんあって、へんちくりんな形の建物がどーんと。大学のキャンパスかカフェか何かみたいです。

さんざん周りをうろついて写真を撮りまくったあげく、何かの間違いで中に入れてもらえないかとVisitor用のロビーに向かったら、受付のおねーさんに「ここはClosed Campusです、知り合いが面会者がいない奴は立ち入り禁止です。でてけ」とやんわり怒られ、外に出たらセキュリティのお兄さんにまたやんわり怒られ、あえなく撤退。入れないのはわかっていたもののやはりショック。

"There are no public visitor center or a shop"だそうです。嘘つき!俺は知ってるよ!某氏がGoogle社内見学したとき、お土産にバッグ買って帰ってきたのを!

あ、そうか、だから"public"って断りを入れたのね。というわけで、技術にはオープンですが、本社警備には大変クローズドなGoogleでした><


■続いてAppleへ
ふたたびCaltrainに乗って、こんどはSunnyvale駅へ。

駅からVTAバス55番で南下するとAppleの本社に到着。外見はGoogleと違ってテクノロジー企業らしい企業ビルって感じです。あたりの交差点にたくさんリンゴマークの住所書きがあります。

先ほどのGoogleでの失態を教訓に、まずはすぐに施設に近づかずInfinity Loopの公道からゆっくり観察することに。あ、6 Infinity Loopに山積みのMac Proがある。一つお土産に欲しい。

Infinity Loopを左回りに進むと、6, 5, 4, 3, ....という風に施設が並んでいます。一番最後が1 Infinity Loop, 本社ビルです。

本社ビル前に到着。お土産屋さん発見。観光バスと観光客らしき人も発見。どうやら思ったより観光客に対してオープンになっているみたいです。

しかし当たり前ながら本社ビルの中には入れないようで、入り口の前で立ち往生。


■あんびりーばぶる!
で、中にも入れないし写真も撮ったしそろそろ帰るかと思っていたら。

http://twitter.com/akisutesama/status/4354424273
http://twitter.com/akisutesama/status/4354453168
http://twitter.com/akisutesama/status/4354498099

まさかのジョブズ降臨!!

目の前3メートルの位置にジョブズが!声をかけたけど無視されてすたすた行ってしまわれた。

いや待て、本物がこんなド真ん前を堂々と歩くわけがない、偽物か影武者だと思って売店のおねーさんに聞いてみたら、"then it might have been"(ならたぶん本物だったのよ)とのお返事が。あと"He usually doesn't answer because he's so busy"らしいので、どうやら本物っぽいです。ああ、来て良かった!

最後に記念撮影してたら建物の中が写るからそこで撮るなとセキュリティのイケメン兄ちゃんにやんわり怒られました。またか!><


■じゃあ帰りましょ
Sunnyvaleの駅前で食ったsushiはなかなかおいしかった。カリフォルニアロール、言うほど不味くないですよ。私の舌がゲテモノ食いなのかもしれませんけど。ただし握りはいまいち、しゃりがなんだか変。食えないことはないけど、近所のスーパーのパック寿司のほうがおいしいと思う。これで4ドルは日本だとぼったくり。

帰りのPalo Alto駅で乗ってきたスタンフォードの学生が目の前でMacBook広げてプログラミングを始めたので興味本位でのぞいてみた。ソースはよく見られなかったけど、たぶんAdobe AirかFlash。集中力が凄くって、乗ってからサンフランシスコの駅についてドアが開いてもまだMacとにらめっこしていた。きっと朝から夜遅く(19時)まで授業があっただろうにと思うと、さすがスタンフォードの学生だと感心するとともに、自分も負けていられないと思うのでした。

2009年9月24日木曜日

アルカトラズなう

1日目に引き続き、2〜3日目。


■2日目
朝起きてまずは近所の散策。Whole Food MarketとWalgreensを発見。

ジャパンタウンへ行ってみるがあまりにも閑散としていておもしろくないので即撤退。伊藤園の充実野菜が売ってあった。

おもむろに目の前を走っていたMUNIバスに興味本位で乗ってみたら降り方がわからず大変苦労した。運ちゃんに降り方を聞いてようやく降りたらなぜかシビックセンターについた。

シビックセンター見学

ダウンタウンへ移動

ダウンタウン見学、Apple StoreでWifi電波を借りたりFallout 3の実物大Power Suitにつられて地元のゲーム店によってみたり。DSとWiiのソフトが日本と全然違う。ほかはにたりよったり

あ、Walgreensにおーいお茶(濃い味)売ってる、$1.69

ケーブルカーでフィッシャーマンズワーフへ

Pier39で飯、ようやくこっちのレストランの作法とか文化的背景がわかった

Pier33で明日のアルカトラズ行きのチケットを入手

適当にバスに乗ったらゴールデンゲートブリッジについた

ゴールデンゲートブリッジを見学。風が糞強い!めちゃ揺れる!落ちる!!ロードバイクにひき殺される!!死ぬ!!><

ゴールデンゲートウェイ公園に移動。広すぎる上に車道があって公園というイメージがしない。地元の田舎道みたいな雰囲気。

なぜかツタンカーメン展をやっていたので入ってみた

やばい、ツタンカーメン展ヤバい、超おもしろい!
日本で一般的に開催されている展覧会と違って見せ方が上手い!展示に移る前に、決められた人数ずつ展示室前の墳墓を模した暗室に誘導され、そこでディスカバリーチャンネルみたいなかっこいいムービーを見る。凄い盛り上がる!ムービーが終わったらいよいよ中へ、入ると同時にツタンカーメンの像がお出迎え!とこんな具合にストーリー性があっておもしろい。美術品を順番に置いて説明テキストおいて終わりじゃなくて、映像とか部屋の構造まで使ってストーリー性を持たせているのが、まるでディズニーのアトラクションみたいだと思った。

2時間もたってしまって19時になったのだが、外がまだ明るい。よく考えたらサマータイムのおかげでまだ日本時間では18時相当なのだった。サマータイムに生まれて初めて感謝した。

近所のWhole Food Marketで晩ご飯を買って食う。普通に食える。おいしい。誰だアメリカの飯が不味いとか言ったやつは。自分にはこれでちょうどいいぐらいだ。


■3日目
朝9時半からアルカトラズへ移動

昼14時半までアルカトラズ観光。とにかくすばらしいの一言につきる。島から見えるサンフランシスコの町並みも、刑務所跡も、とても綺麗で歴史が感じられる。ここの歴史なんてたかだか100年とちょっとしかないはずなのだが、数百年歴史があるはずの地元山口・錦帯橋よりも歴史が感じられるのは、やはり見せ方が上手いのと、音声ツアーガイドがあまりにも秀逸であるおかげだろうなぁと思った。アルカトラズ刑務所の音声ツアーガイドは本当にすばらしい!ディスカバリーチャンネルの世界を自分の足で歩いているような雰囲気がたまらない!
※帰ったら写真と動画うpします。

フィッシャーマンズワーフで遅い昼飯。ただのハンバーガー(10ドル)、これが凄くおいしい。ポテトもマックやバーキンの安物とは全然違って、30分たってもおいしい!このぐらいなら、なるほど料理と読んで差し支えないなぁ。

近所のWhole Food Marketで晩ご飯と朝ご飯を買いだめ

終了


作法や町歩きの仕方が身についてきて、英語も耳に慣れ聞き取れるようになり、おもしろくなってきました。明日はいよいよGoogleとAppleの見学に行ってきます。余裕があればStanfordも!

2009年9月22日火曜日

サンフランシスコなう

思い立ったが吉日ということで今サンフランシスコに来ております。初海外です。
  • 飛行機で9時間10時間は思ったより全然楽。ただし酔い止めと耳栓とマスクとエア枕は絶対必須。どれか一つでも欠かすと結構きつい。
  • 飛行機機内寒すぎ
  • サンフランシスコも寒すぎ(体感で東京の10月下旬以降)、長袖が必須
  • こっちの人は皆さんとっても親切、アメリカ人は意外とフレンドリーだった
  • でも何言ってるかわからん←一番困る、TOEICの点数とリスニング力は全く比例しません
  • SUBWAYの味は東京と代わらなかった(量が多いしピクルスが酸っぱくて不味いが基本同じ)
明日はダウンタウン行ってみたり町になれようかと思います。23でアルカトラズでも見て、24でGoogleでも見て帰る。

2009年9月13日日曜日

iMacもSnow Leopardにしてみた



MacBook Airに引き続き、iMacのほうもようやくSnow Leopardに乗り換えてみました。


■ユーティリティとか動くの?
USB Overdrive
動きました!一番気がかりだったので嬉しいです!
Shades
こちらも動作しました。Snow Leopardで多少マシになった輝度設定ですが、まだまだ明るすぎるので重宝しています。
ただし、画面右上のアイコンをクリックして表示されるスライダーが動きません。輝度設定を変更したいときは、システム環境設定のパネルからShadesを直接起動して変更する必要があります。まぁ、その程度なら全然OK!
MenuMeters
やっぱりダメでした。残念ですが忘れようと思います><


■その他、iMacの気になるところ直った?
画面の輝度が明るすぎる
多少マシになってます。一番最低まで下げれば、以前よりはまぶしくない(気がします、単にコントラストの設定が2.2になったせい?)。でもまだまぶしいです、引き続きバグチケットをAppleに投げてきます。
マウス
相変わらず加速度がオフに出来ない糞仕様です。反応速度自体はマシになっていますが・・・しかも困ったことに初代Macintoshからこうらしいです、伝統だとか。改善されることはなさそうです>< USB Overdrive様々。
ExposeとSpacesのマウス操作仕様
困ったことにSpacesのマウス操作が微妙に変わっています。Spacesをボタンで起動した後、開きたいSpaceを「左クリック」しない限りSpaceが切り替わらない仕様になってしまいました。いままでは「Spacesの起動ボタン」でもSpaceが切り替わっていたのですが。Exposeは従来通りなので差異が発生してます。地味に困るのでこれもバグチケット投げないと。

2009年9月8日火曜日

Mac OS X 10.6 Snow Leopardのeasy_installでPILをビルドするときに気をつけることなど

Snow LeopardにPIL(Python Imaging Library)をインストールしようとして見事にハマりましたので、後学のために事の顛末を記しておきます。


■まず最初に、調べて分かった結論
  • Snow LeopardでPythonを使うときは、デフォルトで付属しているPython 2.6.1を使用すること。
  • Snow LeopardにはPython 2.5.4も付属しているが、こちらは使用するべきではない。
  • Snow LeopardのPython 2.5.4のdistutilには不具合?があり、UnixCCompilerクラスがC言語のモジュールを64bitでビルドしてくれないため、Snow Leopardでは動作しなくなる
  • したがって、C言語のモジュールを使用しているPILはSnow LeopardのPython 2.5.4を使うとビルド出来ない
  • どうしても2.5.4を使いたいときには、環境変数にARCHFLAGS "-arch x86_64"を追加してからPILをビルドするとうまくいくかもしれない(未確認)
  • MacPortやMacPythonからのインストールは実験していないため未確認

※ あくまで2009年9月8日現在での断片的な情報です。皆様がごらんになっている時点では既にMacPort上のPythonやMacPythonも対応を完了しているかもしれませんので、参考程度にご覧ください。でもSnow Leopard上のPython 2.5.4はほんとお勧めしません。


■ことのはじまり
Leopardのころはきちんと動いていたGoogle App Engine SDKが、Snow Leopardにアップグレードしたとたん突然PILモジュールがないと警告を出すようになってしまいました。確認してみると/Library/Python/Python2.5/site-packages/以下に確かにインストールされているのですが、何度試しても警告が消えません。Pythonのバージョンも以前から使っているPython 2.5のままです。これは何かがおかしい、再インストールした方がいいだろうと判断し、http://www.pythonware.com/products/pil/から1.1.6のソースコードを落としてきていざビルド。
sudo python setup.py install
python selftest.py
・・・が、動きません。なにやらImagingMathが見つからないだのなんだのとエラーが出てしまいます。これだけではよく分からないので、直接PILのモジュールをPythonからimportしてみることにしました。
akisute PIL$ python2.5
Python 2.5.4 (r254:67916, Jul 7 2009, 23:51:24)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import Imaging
>>> # 問題なくインポートできました
>>> import _imaging
Traceback (most recent call last):
File "", line 1, in
ImportError: dlopen(./_imaging.so, 2): Symbol not found: _jpeg_resync_to_restart
Referenced from: /Library/Python/2.5/site-packages/PIL/_imaging.so
Expected in: flat namespace
in /Library/Python/2.5/site-packages/PIL/_imaging.so
>>>
ふむふむ、どうやらこの_imaging.soというのがなにやら悪さをしているようです。@tokibito先生にお尋ねしたところ、このsoファイルというのはC言語のソースをコンパイルしたライブラリで、Pythonから動的にインポートできるようにpython.hというヘッダをインクルードしてつくられているらしいということが分かりました。なるほど、それでPythonから直接C言語で書かれてビルドされたライブラリをimportできるんですね。凄いなPython。

となると怪しいのはPILのビルド工程。先ほどのエラーを見ると_jpeg_resync_to_restartというシンボルが見つからないと表示されていたため、インストールに使ったlibjpeg(MacPortよりインストール)に何か問題があったのではないかと推測したのですが、特に問題は見つからず。

次にPILのビルドログを調査。細かいwarningが出まくるのはいつものことなので無視して調べてみますが、一見何もエラーは出ていません。するとあることに気づきました。
gcc-4.2 -Wl,-F. -bundle -undefined dynamic_lookup -arch i386 -arch ppc build/temp.macosx-10.6-i386-2.5/_imaging.o build/
temp.macosx-10.6-i386-2.5/decode.o build/temp.macosx-10.6-i386-2.5/encode.o build/temp.macosx-10.6-i386-2.5/map.o build/
----
中略
----
-L/o
pt/local/lib -L/System/Library/Frameworks/Python.framework/Versions/2.5/lib -L/usr/lib -ljpeg -lz -o build/lib.macosx-10
.6-i386-2.5/_imaging.so
うん、なるほど、原因が分かりました。-arch i386と -arch ppcでしかビルドされていないのがまずそうですね。Snow Leopardは64bitですから、-arch x86_64を追加してビルドしなければならないはずです。

ためしにPython 2.6.1でこの_imaging.soを読み込もうとしてみた結果がこちら。
akisute PIL$ python
Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import _imaging
Traceback (most recent call last):
File "", line 1, in
ImportError: ./_imaging.so: no appropriate 64-bit architecture (see "man python" for running in 32-bit mode)
>>>
ビンゴ!間違いなさそうです!あとは、どうすれば64bitでビルド出来るかを調べるだけです。


■distutilとの戦い
とは言ってみたものの、そもそも一体全体どういうカラクリでpython setup.py installコマンドがgccビルドを実行しているのかが分かりません。まずはsetup.pyのソースを読んでみることにしました。するとdistutils.command.build_extなるモジュールをimportして使っていることが判明。怪しい。Python2.5のシステムライブラリをあさってみると、ありましたありました。


さっそくコードを読んでみると・・・
475         objects = self.compiler.compile(sources,
476 output_dir=self.build_temp,
477 macros=macros,
478 include_dirs=ext.include_dirs,
479 debug=self.debug,
480 extra_postargs=extra_args,
481 depends=ext.depends)
おおっといきなり発見、self.compiler.compileとか怪しさ抜群です。こいつはどこからやってきたのかとソースをたどると、なにやらunixccompiler.pyというモジュールを発見。いかにも私がコンパイラだと言わんばかり。犯人はこいつに違いない。さっそくコードを開いて-archとかで検索をかけてみましたが、i386とかppcとか直接指定している箇所は見あたりませんでした。その代わり別の収穫を発見。
def _darwin_compiler_fixup(compiler_so, cc_args):
"""
This function will strip '-isysroot PATH' and '-arch ARCH' from the
compile flags if the user has specified one them in extra_compile_flags.

This is needed because '-arch ARCH' adds another architecture to the
build, without a way to remove an architecture. Furthermore GCC will
barf if multiple '-isysroot' arguments are present.
"""
----
中略
----
if stripArch or 'ARCHFLAGS' in os.environ:
while 1:
try:
index = compiler_so.index('-arch')
# Strip this argument and the next one:
del compiler_so[index:index+2]
except ValueError:
break

if 'ARCHFLAGS' in os.environ and not stripArch:
# User specified different -arch flags in the environ,
# see also distutils.sysconfig
compiler_so = compiler_so + os.environ['ARCHFLAGS'].split()
----
後略
----
環境変数ARCHFLAGSとかいうのを見てるみたいです。なるほど、じゃこいつに"-arch x86_64"とか追加すればきちんと64bitビルドしてくれるのでしょうか?


■そしてあっけない幕切れ
ここまでなんとか一人で調査していたものの、たまりかねた隣の席の皆さんからアドバイス。

「Python 2.6じゃないのがまずいんじゃね?」

え、何、そういうこと?まぁ念のために試してみるか、ということでPythonを2.6に切り替えて再度PILをビルド。

あ、-arch x86_64がビルドオプションについてる。

あ、python selftest.py一発で通った。

あ、Google App Engine SDKがPILの警告吐かなくなった。

終了。

なにそれ。俺の苦労、何よ。


■あれ?
・・・おかしいな、今日作るはずだったGoogle App Engineのアプリ、まだ10行ぐらいしか書いてないよ><

2009年9月3日木曜日

.tmux.confをいじってtmuxのエスケープキー(prefix)を変える

~/.tmux.confというのがtmuxの設定ファイル、screenにおける~/.screenrcのようです。
制御キー(screenでいうescapeに相当)を設定するには、
set-option -g prefix C-t
unbind-key C-b
bind-key C-t send-prefix
こんな感じで書きます。C-を付ければControlキーが修飾キーになるようです。
.screenrcのときは
escape ^Tt
みたいに書けばOK。

参考にしたページはこちら:
http://ktjx.blogspot.com/2009/08/tmux.html


■トラブルシューティング
間違ってこんな設定を.tmux.confに書き込んでしまうと、
set-option -g prefix t
Tキーがprefixになってしまうためターミナルからexitquitを入力させることが出来なくなりtmuxを終了させられなくなります。Control-Cも試してみましたが無視されてしまいました・・・仕方ないので強制的にMacのTerminal.appを落として解決したのですが、問題がその後。tmuxにはセッションを保持する機能があるので、強制的にTerminalを殺してもtmuxのプロセスはまだ生き残っています。再度Terminalからtmuxを起動すると、tmuxがこの生き残っているセッションを復活させてしまうため、設定ファイルを正しく書き換えても反映されなくなってしまい泥沼に突入します。

ということで、tmuxプロセスを先にkillしてから再度tmuxを起動すれば無事に設定が反映されます。こんな恥ずかしいミスをしでかすのは私ぐらいかと思いますが、何かの拍子にお役に立てば幸いです。

Python 2.5系列では__repr__()でunicodeを返すといろいろトラブルが起きる

Django(正確にはapp engine patch)のmanage.py shellで遊んでいるとき、とあるクラスを生成すると必ずUnicodeEncodeErrorが発生していることに気づきました。具体的には以下のような感じ。
>>> from game.models import *
>>> hts = HeroTemplate.all()
>>> ht = hts.fetch(1)[0]
>>> ht.template_name #問題なし
>>> ht.name          #問題なし
>>> hero = Hero(
... name=ht.name,
... symbol=ht.symbol,
... max_life=ht.max_life,
... life=ht.max_life,
... max_move=ht.max_move,
... move=ht.max_move,
... weapon=None,
... item=None,
... )
>>> hero             #ここでUnicodeEncodeError
>>> ht.createHero()  #上記と同じ処理をやるメソッド、これもUnicodeEncodeError
原因を調べていてわかったのですが、Python 2.5系列では__repr__()がunicodeを返すようにしてしまうとトラブルの元になってしまうようです。
参考にしたサイト:
http://d.hatena.ne.jp/alisue/20090402/1238690818

たとえば、
>>> class Abesi:
...   def __repr__(self):
...     return u'¥u3059¥u305a¥u304d¥u3044¥u3061¥u308d¥u30fc'
... 
>>> abesi = Abesi()
>>> abesi #UnicodeEncodeError
これを実行するとabesiを表示しようとしたタイミングでエラーになります。環境はWindowsXP上のCygwin 1.7 + Python 2.5.4で、ターミナル上ではshift_jisを使っています。始めっからターミナルがutf-8を扱えるような環境なら__repr__()でunicodeを返しても上手くいくかもしれません。
しかしながらどこの環境でも動くとはいいがたい状態なので、
  • __str__()と__repr__()はstrを返す
  • __unicode__()はunicodeを返す
Python 2.5系列ではこのルールを守っておいたほうが無難のようです。Python 3.0からはunicodeがデフォルトになるらしいのでこんな面倒ごとをいちいち考えなくてもよいのでしょうか?いまだにPython 3.0試していませんが、ちょっと興味が湧いてきました。


■っていうかそもそも
Djangoのdjango.db.models.Modelクラスは特にオーバーライドしなくても綺麗な__repr__()を出力してくれるので、デフォルトの__repr__()を使えばよかった><

2009年9月1日火曜日

多少マシになったかな




相変わらずこんなしょぼっちい物を作っていたりします。


■前回からちょっとだけ改善
敵が出るようになりました(キャラの向き滅茶苦茶ですが)。
弾が出るようになりました(タダの自機狙い3Wayですが)。
ちょっとずつデザエモン程度には近づいてきたかなぁと。
あとは自機が動いて弾が出れば一応STGっぽくはなります。

今回作ったところまでの経過をgithubにうpしてみました。
http://github.com/akisute/MyShooting/tree/338e164b4716ec27a6a9b8d384f7714243f53d2e

最新のソースはこちら。
http://github.com/akisute/MyShooting/tree/master


■今回の気づき
弾の発射とか敵の出現タイミングをフレーム単位で計測して実行しているのですが、cocos2dのフレーム時間はかなりばらつくようです。弾が200発程度出ただけでフレーム時間が2倍になったりします。要するに弾の発射間隔が2倍になります。ちょっとこれはいただけない感じ。毎フレームごとに前フレームから何秒経過したかが取得できるので、それを元に時間単位で発射タイミングを測った方がいいかもしれません。

あとはActionがやたら重いです。何が重いってActionの動き自体よりもActionオブジェクトの作成と解放に時間がかかっている感じです。頻繁に起動が変わったり単純直線移動しかしない動きを再現するとき(たとえば高速弾や自機コントロール)は、昔ながらのvx, vyを使った方法のほうが軽くて良さそうです。