文字コードを意識すべし

現在のWebブラウザというのは、いろんな外部コンポーネントも使って作ってるわけなんだけど、例えば、HTMLを解析しながら文字コードを変換なんてしてたら複雑になりすぎてバグを増やすきっかけになってしまう。HTMLパーサーに渡される時点で特定の文字コードで渡すようになってる。そのため、文字コード変換はオープンソースだったらlibicuのようなものを利用したりする (WebKitは現にlibicu使ってる) し、プロプラであっても、Internet ExplorerのようにブラウザじゃなくてOSのコンポーネント(MLANG.DLL)を使ってたりする。ちなみにMozillaではuconvと呼ばれるライブラリを自分たちでメンテナンスしてる。

また、現在のWebブラウザというのは内部的にはUTF-16またはUTF-8を使ってる場合がほとんどなので、コンテンツ(HTML/CSS/JS)が別の文字コードである場合にはそれを変換して読み込むわけなんだ。なので、出来る限りコンテンツに使う文字コードってのは、意識すべきなんだよね。

また、現在の主流のCPU(X86とARM)の場合の例で考えると、7ビットのASCII文字からUTF-16への変換はいちいち while(*a) u = (uint16_t)*a++; なんてコードを書くまでもなくもっと高速化可能になってる。X86の場合は、SSE2 or SSSE3を使ってSIMDでシャッフル演算すれば、一度にASCII8文字をUTF-16の8文字に変換できるし、ARMの場合はNEONを使うことで、同じように8文字のナロー・ワイド変換が可能なんだ。そのため、us-asciiやUTF-8からUTF-16への変換の場合は、このような最適化コードを使ってる可能性がある (現にFirefoxでは使ってる)。もちろんus-asciiやUTF-8の場合で7ビット文字じゃないものを含む場合は、そのパスを使わずに従来通りの変換を行ってるけどね。

us-ascii以外でもやってるかというと、やらないことがほとんどというかやらない。そういう文字コードの場合は文字変換テーブルを利用して文字を変換したりする必要があるから、あえてそんなところに複雑なコードパスを作ることはないだろう。だって、その文字コードはとある言語では必要かもしれないけど、全体として少数派になってしまうからね。

だから、@charset "euc-jp"なんて書いたCSSがあったとすると、Webブラウザ的にはeuc-jp用の文字コード変換コードが実行されるんだけど、おそらくテーブルを使った変換を行うので、そのCSSが7ビットASCIIだけで書かれていたとしても、速度的なことは期待できない。

なので、コメント書く必要がないようなCSSとかJSとかだったら、文字コードをus-asciiとかutf-8とかにして、コンテンツは7ビットASCIIのみを使った方がより速く文字コード変換が行われるかもよってこと。速度を意識する必要がないのであれば別に構わないけどさ。

mozilla-inbound

Mozillaのルールとして、WebKitとは違い、レビューが通ったコードはmozilla-centralに手動でチェックインしないといけなくて、なおかつそのチェックインで問題が発生しないかどうかをチェックインした人がウォッチしなければいけないという暗黙のルールがあった。ウォッチするってことは常にtinderbox (tbpl) をチェックしないといけなくて、自動テストの失敗はなんで失敗したかを調べなきゃいけなかった。で、たまにしかチェックインしない人だと、IRCで「なぜ起きるのか教えてくれ！」って叫ぶ声がよくあった光景だった。

で、Firefox 4が終わったくらいからそのルールをやめようとして、cedarを使ってチェックインをウォッチしないルールをehanあたりが作って、それが実運用された。それがmozilla-inbound。mozilla-inboundへのチェックインはツリーの状態（テストの結果）をウォッチしなくてもよくて、テストが失敗してそうな修正は、コビトさん(人間ね)が自動的にバックアウトするルールになった。また、定期的にmozilla-centralとの同期を（手動で）行うので、一般的なNightlyにはテストがちゃんとパスされたものが入り、Nighlyが不安定なことが減ったはず。

また、チェックイン前のテストでは、try serverと呼ばれるものを使うことで事前にテストを実行できる (要Level 1のチェックイン権限。try serverはchromiumにも導入されてるんだってのは最近知ったけど、MozillaかGoogleのどっちが最初にこのアイデア導入したかは知らない)。で、try serverではどのバイナリをビルドするかとか (Win32の場合は、VS2010でビルドするのもできる。現在のFirefoxはVS2005使ってるけどね)、どのテストを実行するかとかを選べる。TryChooserって呼んでるけど。

mozilla-centralへのマージをやってるのが数名 (EdとかMacroとか)で回してるので、祝日とかが多いと、mozilla-centralにまったくコードが入らないことが起きるんだよね。checkin-neededも同じようにDaoとかやってくれる人が決まってるので、彼らがいないと放置プレイになりがち。まぁ、もう少し自動化できるところは自動化しないとね。

MozCamp Berlin 2011

行ってきた。

キーノートのプレゼンで着ぐるみの制作現場の写真があるのは、どうかと思う。

バッテリーAPIが実装された

JoyStick APIと並ぶ、そこ？って感じのDevice APIで、battery APIってのがGecko 10 (Firefox 10) に実装された。

動くのは、LinuxとAndroidだけで、それ以外のプラットフォームは後で実装されるんだけど、使い方は簡単で、現在のバッテリの残量を見たければ、こんな感じで使える。

alert(window.navigator.mozBattery.level);

もちろん、イベントリスナ登録して、

function update() {
}

window.navigator.mozBattery.addEventListener("chargingchange", update)

こうすれば、ACプラグがつながった、抜けたのイベントがとれるんで、chargingプロパティ参照すれば、現在のACプラグの状態をとれる

これが実装されたおかげで、長年の懸念ポイントだった、ACつなげてないのにThunderbirdがインデックスを作りに行くから、バッテリが持たなくて困る問題を直す気になったてか、Thunderbird 11でやらないとね

Mercurialでのブランチ

まぁ、自分がMercurialユーザーだったらvim-jpの記事を読んで間違いに気づくはずだ。

まず、Mercurialでのブランチというのはどういうものが理解すべき。Mercurialでは、ブランチというのは、一種のtagとheadsの総称でしかない。gitだとローカルブランチとリモートブランチという概念があって、ブランチをpushするときには、特別な方法を取る必要があるけど、mercurialの場合は通常のpushに自分で作ったブランチが含まれてしまう (もちろんheadsが合わなければリジェクトされるし、明示的にブランチへのpushを使う必要もある)。

だから、多数での開発をしてる際に自分のコードを管理するためにブランチを作るのはよくない。Mercurialにおけるブランチは永続的なものなので、pushする場合にはそのブランチは大元のレポジトリへの影響を与えてしまう可能性がある。

でMercurial上で管理されたコードのパッチを書く場合はどうしたらいいかというとMercurial Queue (mq)を使うのが現状ではベスト。mq形式でパッチを作成しておけば、パッチを受け取った人は、qimportで自分のmqに取り込んで、qfinでコードを直接コミットすることが可能。しかもパッチの説明とか作成者情報とかもmq形式に含まれるんで、受け取る側はrebase以外に手間がかからない。mqの使い方は、実際Mozillaで使ってるやり方とかMercurialのドキュメントとかを参考にするといいです。

もちろん一生pushしないレポジトリだったら別にブランチを使うのもいいけど、一生pushしないってそれ寂しくない？

たぶん、vim-jpの人はgitの知識があるから、こういう情報を書いてしまったんじゃないかな？gitの場合で新規コードを書くときはローカルブランチを作って、それで管理するやり方をするからね。ローカルブランチだからpushする際に影響受けないし、削除も簡単だし。

だから、SCMは各々思想が違うから同じやり方が正しいということは一切ない

iPhoneがauに?

日経の飛ばし記事にみえるけどね。問題は、ガラパゴスなネットワークの方にあるから、それをauがどうかするかにかかってる。

日本の3社+1社のネットワークは、一番グローバルなものがソフトバンクだけで、それ以外は周波数や通話・データ通信以外の規格 (メールシステム) がガラパゴスなことが問題なんだ。今のチップセットであれば、周波数の変更ってのは、まぁ大丈夫なんだけど (チップレベルでは複数の周波数サポートしてるはずだし) 。

そもそも歴史から行って、3Gネットワーク自体は、世界で言ってもドコモがほぼ最初に近いんだけど、そこでサポートされた規格は、3Gの正式バージョンを1.0とすると、0.9的なバージョンを採用して、同じ3G、同じ周波数なのにネットワークにつながらないという日本独自仕様になったりするのが、日本のキャリア。これは後に正式なバージョンのネットワークに置き換えられたんだけどさ。

auもそもそもCDMA2000という少数派の規格を採用してる(韓国ではメジャー)のだけど、そもそも過去に800MHzのネットワークで、上下周波数がauだけ逆というトンデモ仕様が使われてて、これも日本独自仕様だった。今は違うけどね。CDMA2000を採用したのも、2.5Gの規格の流れとか、総務省とのやりとりとかいろいろあったらしいけどさ。

イーモバイルは1.7GHz帯というこれもほとんど世界で採用されてない倒れそうな周波数で。。。これは総務省の問題か。

ソフトバンクは買収したボーダフォンがたまたますべてをグローバルなシステムに置き換えたあとだったから、たまたまグローバルな仕様になってるだけという感じ。ソフトバンク自体が設計やってると多分そうならなかったんじゃないかな。

そもそも、iPhone 5がauのネットワークで採用されるんだったら、すでにプッシュメール自体のシステムでMMSを採用 (MMSのゲートウェイでも作って対応)してると思うよ。au上のWindows PhoneやAndroidでCメールをサポートしようとしてる動きを見る限り、MMSを投入するとは一切思えないんで、Appleが折れるとは思えない。だから、この記者は妄想というかauユーザじゃないのかなぁ、マジで。

Mozilla勉強会 @ 東京

東京で久々に勉強会をやります。前回は年明けくらいにやったから、約半年以上ぶりに東京でやります。内容は今週中には確定すると思います。

といっても、自分は行けないんだけどね。だって、MotoGP観に行ってるし

DOM4を実装すると、ACID3がパスしなくなるらしい

ACID3が標準準拠テストだと思ってる人はまだいそうだけど、これは非常にいろいろな問題を持ってるテストで、これをパスしたからハッピーということではない。

で、最近一番面白いネタが、DOM4の現在の仕様だとこのテストはパスしなくなる。Jonasがwebappsのメーリングリストにこの話を投げてる。http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1329.html

The new DOM-Core specification changes some of the behavior for DocType nodes to make them act more like all other nodes in the DOM.
Specifically:

1. They always have a ownerDocument
   
2. They can move between, both using explicit calls to AdoptNode, and
   implicit adoption during for example insertBefore
   
3. They can be cloned between documents using importNode
   

We've written a patch to implement these changes in Gecko (which resulted in a nice reduction in code). However, ACID3 tests for the old behavior which is making it a harder decision to check this patch in. As I understand it this isn't a Gecko specific interaction with ACID3, but all browsers will see the same loss in ACID3 score if they implement the new DOM-Core spec.

で、ACID3自体がダメダメだから、直す話が実際あって、http://wiki.whatwg.org/wiki/Acid3にいろいろ書かれてる。

Visual Studio 11のARMターゲットを遊んでみた

Windows 8でarmがサポートされるんだけど、早速Visual Studio 11のC++で試してみたところ、

• armターゲットのとき、当然_M_ARMが定義される
• arm_neon.hが入ってるので当然NEONサポート
• デフォルトでthumb2のコードを吐く。だから、ARMV6T2ってかARMV7以降のコードを吐く。Windows CE 7のコンパイラと違って、CPUターゲットのオプションが/?で出てこないから、ARMv6以前のCPUサポートはない可能性が
• コンパイラがインラインアセンブラをサポートしてないのに、アセンブラが入ってない。たぶんarmasm.exeの入れ忘れ
• どうもABIはEABIっぽい
• DDKはそもそもarmのターゲット入ってなかった
• いくつかのインポートライブラリが入ってない。wsock32.libとか。ということで全く使えん

そんなところ。gccとの生成コードの質を比べてみたいなぁ。時間があったらやろう

Fennec for Android on VirtualBox

いろいろなものから現実逃避したくなって、ちょっと作ってみたやつ。VirtualBox上のGingerbreadで動くのは確認した。VirtualBoxで動いてるってことは、CPUはarmじゃないってことだけどさ。

libvpxがGoogleのクセにx86上でコンパイルできないとか、long doubleへの変換のgcc関数(__extendsfdf2)がandroid NDKに実装されてないから、実行時にエラーになるとかいろいろ問題あるけどね (そのクオリティでNDKをだしてしまうGoogleのAndroidチームのやっつけぶりは正直すごい）。

いろいろな問題が片付いたらバイナリをどこかに置くことにするけど。

iOS用の...

Dougとか一部のモバイルメンバで作り始め、一旦止めてたんだけど、Ted (ビルドスクリプト系のモジュールオーナー) がrebaseして、動くようにしたらしいiOS用の例のヤツ、最近まじめにmozilla-centralにコードを入れ始めてるんだけど、IRCで今日ネタになってた。

17:17 (glandium) actually, ted is refreshing and landing his iOS patches. once something gets running, going further or not will be decided
17:21 (vicarious) Mozilla should try to release firefox for ios. If Apple rejects it then that's on them, they'll have to face public scrutiny on that count.
17:27 (glandium) gcp: not necessarily, a lot of people are running jailbroken iOSes, and providing an awesome Firefox could be an invitation for more people doing so
17:28 (vicarious) glandium: yes, that too...good point!

ノーコメントということで

25MB程度のDLLをPGOで作ろうとするとLINK.EXEがクラッシュしてしまう

25MB程度ってのは、FirefoxのコアモジュールであるXUL.DLL。Mozillaでは現在Win32 (x86)はVC8を使ってて、Win64 (x64)はVC9を使ってるんだけど (なんでWin64だけVC9使ってるかというとコンパイラのバグのせいで生成したコードが正しくないから)、現在ビルドチームでVC10に移行することを計画してる。

FirefoxというかGeckoでは、メモリ関連のモジュールは、VCのCRT内部のメモリ関数じゃなくて、jemallocというFreeBSD由来のモジュールを差し替えてる。VC8とかVC9だと、CRT (MSVCRT*.DLL) のソースコードがコンパイラに付属しているので、それをコンパイルしてメモリ関連だけ置き換えて使ってるんだけど、VC10からはビルド可能なソースコードが付かなくなった。その関係で未だにVC8とかVC9を使ってたんだけど、Kyleがハッキーな方法を見つけたんで、VC10を使ってもjemallocが動くようになった。そのため、今VC10で動く (=自動テストがちゃんと通る) ように一部のメンバでいろいろと動いてる。

Win64版はVC9を使ってビルドしてて未だオフィシャルではないけど (Nightlyはある)、自動テストが毎回走ってて、JavaScript周りの一部のIssueを残して問題なくはなってる (多分GC周りっぽいんだけど、手元で再現できなくてホント困ってる)。当然Win64版もVC10に移行する計画があって、ビルドチームのArmenはツール周りで、その他はほぼ僕の仕事でもあるんだけど、最近というか今週テストしてみて、PGOを有効にした状態でビルドができないという問題にぶち当たった。

でなんでかとそのデータを見てみると、Win64版のリンカ (LINK.EXE) がクラッシュして内部エラーで終了してる。でさ、Win32版のリンカ (Win32版のリンカでもWin64の実行イメージは生成できる) で試すと問題なくパスする訳だ。

ということで、mozilla-buildを直せばビルドは可能にはなるんでとりあえず回避方法は見つかったけど、これって直してもらえないかなぁってホント思う。関数のエントリ探しにいって、Access Violation起きてるみたいだけどさ。

大人女子スマケーにおける残念なDOM実装

テスト端末として、"大人女子スマケー" 007SH Jを入手した。

Androidへプリインストールされた標準ブラウザでいろいろテストした結果、これはDOMの実装として残念な状態になってる。

ハードウェアキーボードといっても、実際は常にIMEを経由するような実装になってるので、テキストボックスとかでは、常にIMEがオンの状態で動く。

でさ、keydownとかのイベントってのは、DOMでは以下のように定義されてる。

A user agent must dispatch this event when a key is pressed down. The keydown event type is device dependent and relies on the capabilities of the input devices and how they are mapped in the operating system. This event type must be generated after the key mapping but before the processing of an input method editor, normally associated with the dispatching of a compositionstart, compositionupdate, or compositionend event. This event type must be dispatched before the keypress and keyup events event associated with the same key.

IMEがオンであっても、今のブラウザはkeydownイベントは発生してるんだけど、残念な事に日本語入力 (入力方式: 漢字) の時には、keydownイベントが発生しない。まずこれはどうかと思う。(Firefox for Linuxも同じなんでどうかと思う)

もっとすごいのは、入力方式を半角アルファベットにしたとき。その場合はkeydownイベントが発生するんだけど、その際にIMEがオンになってることを示すような特殊なkeycodeを返さずに、その今入力しようとした文字が入る。10キーだから[a]って押しても、未確定の状態でaが入力されるのに、keydownイベントで[a]のキーコードがkeyCodeに指定されて、その後keypressイベントも発生して、"a"が入力される。

入力モードが半角アルファベット

1. [a]を入力
2. keydownイベントが発生。keyCodeは"a"のキーコード
3. keypressイベントが発生。keyCode/charCodeはaの文字
4. もう一度[a]を入力
5. keydownイベントが発生。keyCodeは"b"のキーコード
6. keypressイベントが発生。keyCode/charCodeはbの文字

keydownのkeyCodeがおかしいのはまぁいいとして、文字を確定もしてないのにkeypressイベントを発行してるってのは、DOM的にどうよ？。DOM3的には、textinputがあるけど、過去との互換性どうするの?

で、Fennecはというと、、、うーん、ハードウェアキーボードの実装に致命的な問題があるので、Android Market上で、この端末はブラックリストに入れると思う。Firefox 8か9で直すから、その時にはブラックリスト解除するけどさ。

text-overflowの仕様が複雑になってる話

Firefox (7ね) でもtext-overflow: ellipsisが実装されたわけだけど、text-overflowのスペックがcss-uiに移った関係上、Tantekがいろいろなことを細かく追加してくれてる。それらの話は勝手にTantekが書いたわけではなくて、いくつかの議論が過去にあったことをちゃんと反映したということが事実でもある。

でさ、IE9が出たときに一番感心した点でこのtext-overflowの実装がちゃんと最新の話を追従してきてたというところ。最新の仕様でちゃんと定義されたものの一つとして、スクロール時の動作ってのがあるんだ。

<div style="width: 5em; text-overflow: ellipsis; overflow: scroll;">
  AWESOME
</div>

こんなCSSがあるとすると、スクロール可能な状態でかつ省略文字(...)がつく状態になる。で、スクロールしたらどうなるかというと、ちゃんとスクロールに追従して、"..."を表示する場所を変えなければいけないってことになったんだ。で、これを最初にちゃんと実装したのがIE9だった。で、複雑すぎるテストケース (rtlにしてみるとかいろいろあるよね！) を書いてみてもIE9はまともに実装されて感心した。

ちなみに、ちゃんとOpera 11.50ではこの仕様にちゃんと追従してて感心した（けど、rtlになったとたん破綻する話は相変わらずだったけどね)。

これFirefox 7でもちゃんと実装してあるんで、最新仕様に追従してないのはWebKit系だけっていうことになるんだけど、これってもうWebKitの最新版で追従できてたっけ?

IVSというかUnicodeに見る日本政府のダメな感じ

UnicodeでのIVS (Ideographic Variation Sequence) の倒れそうなお話

IVS (要は異体字のサポートね) ってのはUnicode 5.1で導入されたもので、簡単に言ってしまえば、"渡辺"の"辺"っていろんなバリエーションがあるじゃない？で、それをどうにかできるものなんだよね。それだけ聞くと、おぉ！いいじゃない？って思うんだけど、まぁ、聞け

"辺"の例は、この日経の記事にあるけど、これはわかりづらいから、もっと簡単な例をだす。

U+53DFの異体字一覧があるわけだけど、なんか気付かない?。同じ文字としか見えないものがダブってるだけだよね。

Adobe-Japan-1ってのは、その名の通りAdobeのフォントで定義されてたものヤツ。ある意味出版系で使われているから標準の一つであるよね。もうひとつ、Hanyo-Denshi ってのは、汎用電子情報交換環境整備プログラムで定義されているヤツで要は住基ネットとかe-Japanとかで絡んでたヤツってこと。明らかに正規化を怠ってる感じになってる。

でさ、同じ時期に両方がサブミットしてるんだったら、正規化に失敗するってのだったら、まあ、しょうがないよね、どうしようかって事になるんだけど、どうもAdobeが字形の一覧をサブミットして公開されたのが2007年で、日本政府系のフォントのは2010年。ということで明らかに日本政府関係がやっちまった感じっぽいんだよね。

また、いろいろな話を探っていくと、日本政府関係者が同じっぽい字形が入ってるのを知りながら同じ字形をサブミットした理由ってのが、同じ字形かどうかが分からないから別の字形として申請したというアホな理由ぽいらしいんだけど、関係者に会う機会があったら、是非ホントのところを聞いてみたい感じ。ていうか、Adobe呼んで相談すればいいだけの話じゃない?

こんなアホな理由で同じ字形が複数登録されるくらいだったら、日本の政府関係者は、国際規格に関わらない方がいい規格になると思うのは、オレだけ?

Firefoxの今後のリリーススケジュール

簡単に言えば、マジでスケジュールベースリリースに変更する。これは去年末(12月にそういうアイデアで合意してて、そのために各社どんな風にやってるかという話までしてた)にそういうスケジュールに変えるぜ！って話になってるんで、昨日今日で決めた話ではない。ちなみに現在のドラフトはこれ。

Comitter的には、mozilla-centralで開発してて、auroraで問題があれば、aurora上でBacked Outされるだけなんで、うまくスケジュールに間に合うようにやる必要があるってだけだね。

ちなみに、アドオンはどうするんの？(API Breakに対してどうするの)って話で、Benjaminとかの回答がカオスだったのは、どうしようもないけど、それは今後変更ポイントをDeveloperにちゃんと説明できる何かを用意したいらしいよ(アドオンチーム曰く)

Water leak

バスタブに水を溜めてる最中に寝ちゃって、気づいたら水浸しになったなんてこと、ベタにある話としては聞くじゃない？。アメリカのホテルに泊まった時に上の階の人がそれやらかしたよ

そんなこと起きれば、下の階の自分に当然被害があるわけだけど、上からこんな感じで水漏れが。。。

朝起きた時に気づいたから、何が起きたかどうかわかんなかった。ベットから下りたら、全面水浸しだし。

オレのせいじゃないと言い訳しないといけないから、フロントデスクに文句言うんだけど、英語でどうにかしてくれっていうときに、水漏れって言葉を英語で説明できなくて、結構変化球な英語になってしまったのは言うまでもない。どうもwater leakで通じるみたいだけど。。。朝っぱらからこんなこと起きるとは思わなかった。

Firefox 4 for Android

先に言っておく。

• WOFFのサポート入ってない
• IndexedDB使えない
• HTML Form validation使えない

Firefox 4 on pandaboard (Ubuntu 10.10)

pandaboardを入手してたんだけど、やっと遊び始めた。PandaboardはTI OMAP4 (Dual-core Cortex-A9 / PowerVR SGX 540) を使ってるもので、今のスマフォが使ってるものよりも結構速い

このデータはSunSpiderのベンチマークを(ARM用のビルドを作成して)Firefox 4でとったもの。ちなみにHTC Desire HDだと2800msくらいになる。

============================================
RESULTS (means and 95% confidence intervals)
--------------------------------------------
Total:                 1984.1ms +/- 0.7%
--------------------------------------------

  3d:                   354.2ms +/- 1.3%
    cube:               139.8ms +/- 2.0%
    morph:               65.2ms +/- 5.1%
    raytrace:           149.2ms +/- 3.5%

  access:               290.7ms +/- 2.5%
    binary-trees:        47.1ms +/- 3.5%
    fannkuch:           116.6ms +/- 6.9%
    nbody:               47.1ms +/- 6.9%
    nsieve:              79.9ms +/- 2.0%

  bitops:               105.1ms +/- 1.8%
    3bit-bits-in-byte:    5.1ms +/- 8.0%
    bits-in-byte:        50.4ms +/- 1.2%
    bitwise-and:         12.3ms +/- 5.5%
    nsieve-bits:         37.3ms +/- 2.9%

  controlflow:           21.5ms +/- 7.2%
    recursive:           21.5ms +/- 7.2%

  crypto:               181.5ms +/- 1.9%
    aes:                 94.5ms +/- 0.8%
    md5:                 51.8ms +/- 4.7%
    sha1:                35.2ms +/- 5.2%

  date:                 279.9ms +/- 1.9%
    format-tofte:       173.9ms +/- 2.6%
    format-xparb:       106.0ms +/- 2.9%

  math:                 144.1ms +/- 1.2%
    cordic:              39.7ms +/- 1.5%
    partial-sums:        47.5ms +/- 2.3%
    spectral-norm:       56.9ms +/- 1.7%

  regexp:               123.1ms +/- 3.9%
    dna:                123.1ms +/- 3.9%

  string:               484.0ms +/- 1.0%
    base64:              44.3ms +/- 3.3%
    fasta:               96.4ms +/- 3.1%
    tagcloud:           146.4ms +/- 1.5%
    unpack-code:        135.5ms +/- 1.7%
    validate-input:      61.4ms +/- 3.2%

Pandaboardで評価できるものにUbuntuがあるんだけど、Firefoxのビルドオプションを見ると、ARM用のビルドオプションを全くと言っていいほど使ってないってのは、それはどうかと思うね。Ubuntu 11.04とFirefox 5くらいの組み合わせだとそこらは解決できてると思うけどね (すでにnspr側にいろいろ最適化いれてある)。

転職エージェントからのメール

昔使ったことのある転職エージェントからこんなメールが今日来た。ちょっと頭に来たので、個人名が特定されない程度で

Subject: 地震・津波のお見舞い

〇〇　○様

東北地方太平洋沖地震のお見舞いを申し上げます。
このたびの三陸沖地震および津波の被害に遭われた皆様、
およびご家族、関係者の方々にお悔やみとお見舞いを申し上げます。
皆様のご関係の方は、大丈夫でしたでしょうか。
一刻も早い復旧と安寧の回復を願っております。

ご無沙汰致しております。
これまではあまりお役に立てませんでしたが、
ご活躍のことと思います。
ところで景気については、まだまだ回復感はありませんが、
そのような時期に、良い求人募集があります。
皆様のご存知の方で、良い方がいらっしゃれば
紹介いただけませんでしょうか？
ご紹介頂いた方には、些少ながら薄謝申し上げます。
よろしくお願い致します。

ーーーーーーーー　求人案件　ーーーーーーーー

転職エージェントってのは、大体その決まった人の年棒の3割くらいがそのエージェントに支払われるから、エージェントも必死なんだろうけど、このSubjectは不謹慎だよね。

開発レポジトリ

内緒にしてるわけでもないけど、現状のまとめ。みんなわかってなそうだし。

• mozilla-central
  Fennec 4.0用に現在オープン。Fennec終われば次の開発プランに合わせたレポジトリに移行するはず
• mozilla-2.0
  Firefox 4用。
• tracemonkey
  JavaScriptチーム用の開発レポジトリ。彼らがPost Firefox 4向けで利用中
• build-system
  ビルドスクリプト/build config用の開発レポジトリ。Post Firefox 4に向けてビルドスクリプトのクリーンナップを現在行ってる
• jaegermonkey
  Type Inference用の開発レポジトリ

その他、birchとかgraphicsとかあるけど、それらは今後の開発プラン向けの奴ね。だからmozilla-centralを追っかけても最新の情報がわからなくなると思うよ

初心者が陥りやすいCSSの間違った理解

一瞬気付かなかったけど、こんなCSS書いて、Chromeしか動かないと言っている人がいるらしい。まさに間違い探しだね！

#transformSample img {
-webkit-transform: rotateY(0deg);
-webkit-transition: -webkit-transform 0.5s linear;

-moz-transform: rotateY(0deg);
-moz-transition: -webkit-transform 0.5s linear;

-o-transform: rotateY(0deg);
-o-transition: -webkit-transform 0.5s linear;
}
#transformSample a:hover img {
-webkit-transform: rotateY(180deg);
-webkit-transform-origin: 50% 0;
-webkit-transition: -webkit-transform 0.5s linear;

-moz-transform: rotateY(180deg);
-moz-transform-origin: 50% 0;
-moz-transition: -webkit-transform 0.5s linear;

-o-transform: rotateY(180deg);
-o-transform-origin: 50% 0;
-o-transition: -webkit-transform 0.5s linear;
}

なんか、これ書いた人、マークアップエンジニアって名乗ってるらしいけど、たぶんその会社は人が多いから、その人はHTMLしか書けなくて、別にスタイルシートエンジニアってのがいるんだとオレは信じてる!

Microkia

NokiaとMicrosoftの提携のニュース。ちょっと感想を書きたくなった。

Microsoftにとってこれが失敗してもそんなに痛くはない。そもそも失敗しているんだから。でもNokiaにとっては、これが失敗したら会社ごと傾くとしか思えないね。Nokiaも失敗しているといっても、従来のNokiaユーザーというのがいたわけ(Nokia N8の売り上げを見ればわかる話)だけど、それに喧嘩を売るような戦略。それに一番重要なのは、今回の発表がフラグシップであるNokia E7が発売になったタイミングという、最悪なタイミングの悪さ。

Nokiaに一番欠けていたのはハイエンドスマートフォンの戦略だ。彼らにとってはMeeGoがその役目になるべきだったんだけど、市場投入を未だ出来ていない。彼らの一年前の戦略が一番痛い形で失敗していたわけだ。

また、Nokiaの端末で最速のハードウェアを採用しているのは、Nokia N900で、TI OMAP3430。これはMotorola/VerizonのDroidと同スペック。一年以上も前のハードウェア。ハードウェアの市場投入に関しても今は遅れをとっている。これについてはいくつかの言い分があるとは思ってて、今のAndroid端末とかは毎日充電するのが当たり前な感じで且つ、電話として使うことをそんなに考えてない。そこの考えがNokiaだとまず電話ありきで物事を考えている節があって、バッテリの容量と使用用途、時間を考えてハードウェアを決めてる感じだから、なんとも言えないけど。少なくともS60の最初のバージョンが出たときは、Nokiaが最速のチップを使っていたのだから、市場投入までのスピード感が現在では欠けている。

もうひとつの問題。現在、Nokia Platformに対しての開発者の囲い込みに失敗しているところ。素晴らしいOS、ハードウェアを作ったとしても、ソフトウェアがなければ意味がない。そのエコシステムの作成に完全に失敗している。ドキュメント、ツールチェイン、統合開発環境。すべて。これはQtでカバーする予定だったんだけど。

この問題点を解決するには、Android、Windows Phoneのどれかを採用するってのは理にはかなっている。WebOSの場合は、そもそもこれらを解決する方法にはならないだろう(エコシステムの構築を今更できるとは思えない)。また、Androidを採用しても、遅れて参入してポジションをゲットできるかというところだろうな。Nokiaの今までのスピードだとMotorolaやSamsung、HTCに勝てるとは思えない。というところで、Windows Phoneなんだろうなって感じかな。

MicrosoftのWindows Phoneの戦略も中途半端で、AppleのようなMarket StoreにAndroidのような開発しやすい開発言語(C#/.NET) というところなんだけど、どっちも中途半端としか思えない。しかもNative Applicationを許可しない状態だから、BlackBerryと同等としか思えないんだよね、この戦略だと。BlackBerryのようなメッセージング統合とかがあれば別だけど、売りとなる機能にかける状態だから、どこかで仕切り直しが必要だとは思うけど。

この負け犬同士の連合が今後どうなるのかは非常に楽しみ。それはそうと、SymbianはSymbian Foundationのままでやってればよかったのにね(富士通とかSymbian採用している会社、どうするんだろ)。NokiaとしてこのMicrosoftとの決定がつい最近だったというのはホントよく分かるよ。

003SHが名前通りガラパゴスな件について

システムフォントに、"モリサワ 新ゴ R"とかを選択できる003SHなんだけど、このフォント、/system/fontsに存在しないデザインになってる。なんで、どこにフォントがあるか調べてみた。

Androidのソースから見ると、DalvikのFramework内でフォントリストを持っているのではなくて、Skiaのところでリストを持ってる (だからTypefaceでフォントリストとかを持ってない)。だから、Skiaを見れば、どうフォントを読んでいるかはわかるわけだ。

と言いたいところなんだけど、Apacheライセンスなんで変更差分は分からないわけだけど、まぁ、そんなんは難読化する訳でもないから、バイナリをダンプしたところ、以下のパスにフォントを持っている。

フォント名	フォントパス
LC太明朝	/system/etc/tmp/V20L5b42M84nB
SH_Mincho-P	/system/etc/tmp/V20b4J24M84nR
SH_Crystal-P	/system/etc/tmp/c22b11O14C92rR
モリサワ 新ゴ R	/system/etc/tmp/c30c1d24G94oR

フォント一覧がほしければ、Skia使わないと各デバイスで互換性がとれないってことですか。ださっ

32bitプラグインを動作させる

Firefox 4用には投入しない (許可でないし、そもそもWindows x64版のFirefox 4はリリースしない) けど、x64版でも32-bitプラグインを動かすための調査は終了してるので、そのメモ

IPCのコンパチビリティ

IPC(プロセス間通信)を利用して64bitプロセスなfirefoxと32bitプロセスなplugin-containerと通信することで、64bit版Firefoxでも32bitなプラグインを動作することができるんだけど、一応ポインタとかは64bitとして扱うようにIPCで定義している。なので、問題なさそうな気がするんだけど、調べてみると一つだけ問題点があって、32bitなuint32に互換性がないんだよね (Mac OS X以外)。32bit版だと64bitで通信してて (uint32を扱うつもりがsize_tとして扱われて、なおかつsize_tは64bitとして通信されることになってる)、64bit版は32bitで通信してる。32bit版の方が変だろということでちょっと話したところ、折れない感じなんで、64bit版でもuint32を64bitで通信するように変えることにした (ダサイ)。これはpost Firefox 4で入れる予定

あとは、プラグインのバイナリフォーマットをチェックして32bitだったら32bitのplugin-containerを起動するようにするとか、Firefox 32bitのインストールパスをレジストリから自動認識するとかいろいろあるんだけど、そんな感じで直したもの

バイナリは、http://wiki.mozilla-x86-64.com/Firefox:DownloadにFirefox-4.0b12pre.en-US.win64-x86 64.installer.plugintest.zipとして置いておいた。Just testもの。あ、そうそうx86のNightlyをインストールしないと動かないよ

パッチが見たい? MozillaのMercurialのユーザーディレクトリのどっかに置いてある

Windowsは分かったから、Linuxは？。うーん、Windows版commitしてからかなぁ

Nokia N8を買った

久々に自分用の携帯電話というかスマートフォンを買った。Nokia N8。買ったのはSparco

Symbian^3になっての最初のプロダクトのN8なんだけど、前に使ってた5800XMに比べて、反応はすごく良くなっている。CPUが1.5倍クロックが上がってるんだから、当然ではあるんだけど。ホームスクリーンががらっと変わってはいるけど、それ以外に関しては、そんなに変わってない。メッセージとかでタッチスクリーンでスクロールができない（スクロールバーを触らないといけない）とかも相変わらず。UIの変更は、次のSymbianでだったような。

そのかわりカメラはヤバい。今までのどの携帯電話＆スマートフォンで最高の出来かも

日本語化もいつものようにメモリカードに\Resource\Fontsディレクトリを作って、そこにフォントをコピーすれば表示可能。あと、MMS使うためにUser-Agentを変更。これは開発者証明書が必要になる。

あとは、日本語入力だけだけど、これは管理工学研究所次第かなぁ。。。

2010年を振り返る

2011年になってしまったんだけど、2010年を振り返る。てか今年もいろいろあったというか。

ついに35歳になる

エンジニア限界説の35歳ですよ、ついに。はっきり言ってマネージメントやるのを(しかも大きい会社)経験してたし、エンジニアだけでここまで来たわけでもないんだけど、35歳で限界説を言うような人たちは、自分のバリューを作れなかっただけだと思うってのが、最近よく感じること。

あと、日本でもハッカーを育てないと！って言ってる人もいるけど(その前にハッカーなんて言葉がダサい)、それよりも60歳までコードを書いてもいい環境にすることが、先だと思うけどね。コードをずっと書いていたいんだった、日本の企業じゃ無理な状態なんだから (外資でエンジニアを大切にする企業であれば、50歳でもコードと喧嘩できるし、現にしてる)、エンジニアが日本の企業に寄り付かなくなるとおもうけどね

自分の書いたコードでセキュリティバグ

今年一番やっちまったヤツだね。書いたのは、2010年ではないんだけどさ。これマジで凹んだ。

外で話す場面がたくさん増える

何回かはパネルディスカッションという形でパネラーやったり、大学院の授業とかいろいろと話すことが多かった。プレゼンテーションというと、なんかスマートなものを意識する人が多いと思うけど、個人的に日本人のプレゼンテーションでスゲー面白い、参考になるってのは、非常に少ないんだよね。

個人的にベースになってるのは、Brian Valentineのくだらないプレゼン。あのインパクト勝負には初めはショックを受けたよ。基本シンプル＋インパクト＋パッション＋面白さというのが個人的に追い求めるものなんだけど、そこももっと追求しないとね。

Win64版のFirefoxがNightly化

春にトロントのビルドチームといろいろやって、Nightlyにいれてもらったんだけど、これで結構手が離れた。っていっても、Firefox 4の次でWin64を正式にするという話もあるんで、ちょいまだやること (32bit Pluginを使えるようにするとか) が、まだ残ってるけどね。

その他

ホントはもっといろいろあるけど、大人の事情で書けないね。今年も宜しくお願いします。Firefox 4とThuderbird 3.3?のやり残しが先決かな?