Android 1.5だとMMSがまともに動く

先日自分の持っているAndroid Dev Phone 1を1.5(cupcake)にアップグレードしてみた。起動画面が変わったり、ちょっとアイコンが変わってたり、WebKitのバージョンがあがっていたりするのだけど、個人的には、MMSがまともに動くようになってるのが一番大きい変更点というか一番大きい修正点。

実験する限り、1.1までのファームだと、MMSを設定したとしてもProxyの設定を反映してくれないので、SoftbankのMMSのメールを引き出せなかった。1.5へアップグレードしたところ、Proxy Serverの設定をちゃんと読み込むようになった。

詳しくない人に説明すると、Softbankのケータイ電話では、メールシステムにはMMSを採用している。これはi-modeのようなガラパゴスとは違って、ケータイ電話における世界標準のメールプロトコルの一つ(簡単に説明すると、世界中ではSMSが一般的に使われるんだけど、サイズが大きい場合はMMSを利用している。ちょっと違うけど)。

ただ、Softbankのイヤらしいところは、特定の地域以外では、Proxy ServerがUser-Agentなどのヘッダをチェックして、登録されていないものだと接続をはじくようになっている。そのためNokiaな人たちでは、メールを送受信するために、それ専用のProxy Server(YaPN)を作ったり、User-Agentを偽装するのが一般的だ(最近は絵文字のシステムまで移植する人たちも現れているけどね)。

なので、それを偽装できれば、AndroidであってもSoftbankのメールの送受信ができるわけだ。

Proxy Serverさえ作れば、こんな感じでメールの受信が可能になる。Dev Phone買った時に作っておいたものがあったので。

V8のx64 JIT

久しぶりに、Chromeで使われているGoogleのJavaScriptエンジンである、V8のソースツリーを同期したらx64ネイティブのJITコードがコミットされてた。

けど、ビルドできないけどね。

ついでに、Mozillaのはどうなんったんだという話を追加しておくと、TraceMonkeyのx64コードはちょっと前に削除されたんだけど、reduxのツリーにあるx64コードを持ってくる予定らしい。ただ、reduxのツリーのものをそのまま持ってきても、ビルド通らないし、実装が1/3足りないので、実装し直す必要がある。patch branchとか。

Core i7の64ビットでのパフォーマンス？

Core MA系だと、64ビットモードではMicro Fusion / Macro Fusionが動作しないけれど、Core i7だと動作するようになったようで、これがパフォーマンス向上の理由と言われていて、実際改善しているらしいのだが、実データを見たことがない。

Core i7のマシンがとあるところにあったため、rsaperfを利用して実データをとってみた。

rsaperfというのは、NSSに含まれるテストスイートの一つで指定した時間RSAの暗号化を行うベンチの一つだと思ってください。

データをとったのは、Core 2の1.86GHzとCore i7 2.67GHzとAthlon 64 3500+ 2.2GHzの三台。GHz単位のデータをとったとしても、Core i7が一番速いんじゃないかなと予想。

なお、実行内容はこれ。

rsaperf -e -k 4096 -p 30 -n none

まず、一秒間に何回実行できるかのデータ。シングルスレッドで実行しているので、コアの能力を見る。

予想通り、Core i7が一番速い。ただ、Althon 64 3500+ (Socket AM2の方) も健闘してるっていうより、Core i7ぶっちぎりじゃないんだけど。。。

NSSのRSA暗号化ライブラリ自体がOpetron上でかかれたアセンブラがベースになっている以上、AMDにも有利なものの可能性が高いものだけど、思ったよりCore i7が速くないということはわかった。

採取した各CPUのクロック数は全然違うので、GHz単位のデータに変換して、出し直す。

これが上記のデータをGHz単位に変えたもの。

Core MA系からCore i7に変わっても、5%くらいしか向上してない？。ってか、Althon 64 に大幅に負けてる。Phenomくらいクロックが向上している場合は、Core i7でも不利ってことか。

このデータ見て、64ビット環境のサーバー買うんだったら、やっぱりOpetronなのかなぁとつくづく思った。

eglibc

Drepperは普通のバグ報告だと、(面倒で修正コード作らなくても)すぐ修正してくれる感じのヤツだけど、確かに扱いづらいヤツだよね。

gccのフォーク (EGCS) のときは、gccの開発スピードが遅いことが発端だった気がするけど、Debianの決断はARMがらみのところっぽいね。Androidも別のCライブラリ使ってるし。

少なくとも選択があるということはよいこと。

エンジニア系の会社はマネージメントを軽視しすぎ

今の会社を辞めることになったんだけど (ある意味違った勉強をさせてもらいました)、前の転職活動の時の話。

そのとき、エージェントにそそのかされて、とある大手SNSサイト (m...) を受けに行ったんだが、個人的にはどういう人がやっているのかどうかという点においては興味あった。実際会った人事の人はセンスを感じない微妙な方 (すみません) だったのだけど、そのときに、CTOやってる人が途中から同席してきた。

その人はYahoo! HQにもいたような人で頭の回転も速そうで、会った印象ではその人の下でやるのもありかなとは思った。

そもそも、SNSというビジネスの限界点というのは容易の想像ができる。サイトの成長の鈍化と2、3年遅れてrevenueの鈍化が起きてくると思ってる(広告収入というのはそういうもの。広告を載せる先を選ぶ決め手は現在のリアルタイムの情報じゃないでしょ？)。そのため、その事業をやっていても停滞は起きるのは目に見えているんだ。会社を成長させるとかではなくて、次の柱を作るなり、市場にインパクトを与える何かを作るべきだと思ってた。そもそもSNSの構造上、データマイニングとかをやってきているはずなので、そこらのノウハウを生かせて新しいサービスをやるべきだと個人的には思ってた。だからそのSNSサイトには興味ないんだけど、受けに行ったんだ。

そういう考えだから、「...iというサイトには一切興味がない」という話を面接でしたんだけど、そりゃ当然面接落ちるよね。

余談すぎた。

その時の面接でちょっと興味が引かれてたのはマネージメント手法の話で、ベースの考えとして、CTOの配下にすべての人をラインとしておいていているという話。(実際バーチャルチームを複数作って、リーダーを作ってるのは、容易に想像はできるんだけどさ)

って話を聞いてたのに、最近別のエージェントと会ったら、その会社、開発のマネージャ募集してて笑った。一年やって失敗したんだね。

今の会社もそうなんだけど、エンジニアを多く抱える会社はマネージメントを軽視しすぎ。

LingrとRejawサービス終了のお知らせ
http://japan.cnet.com/blog/kenn/2009/05/01/entry_27022150/

この話だって、結局のところマネージメントができてなかっただけでしょ？。いろんないいわけしてるけど、それにつきると思うよ。Googleだってそこらを軽視してたのが以前の勢いがなくなったことに繋がっていると思うし。

マネージメントがまともではなければ、1+1=2ができなくなる。優秀な人材を雇っても、彼らを生かす道を造るのはマネージャの仕事だし、モチベーションを維持させるのもそう、個々の能力を今必要なことにマッチさせるのもそう。マネージメントという言葉を理解できなければ、この人は失敗し続けるんじゃないかな。そんな気がする。