2015年に買ったもの

買ったのはこれだけらしい。

Nexus 5X

Nexus 5もおそらくAndroid Mでアップデートはなくなるだろうしってことで開発端末として購入。Cortex-A57を採用したものを持ってなかったてのもある。まぁ今後二年間の開発端末＆海外出張時の端末として利用するつもり。

Hikey 96Boards

やっと手頃な値段で買えるARMv8な開発ボードがリリースされたので購入。ARMv8なコードを書く際の実機として利用。まぁそこそこ速いけど、big.LITTLEのリトル側として考えればもっと遅くて電源効率が高いものでもよかったのではって思ってたら、今年Cortex-A35が発表になった。

bq Aquaris E4.5

Ubuntu Phone。普通に日本語フォントが入ってるので日本語表示可能。思ったよりパフォーマンスは悪くないけど、Firefox OSと一緒でAndroidとかiOSの置換って意味だとインパクト欠けるよねってところでしょうか。

細かなものだとMicrosoftのマウスを購入しまくってたとかはあるけど、そんなに買ってないね。USに行った時にSurface Bookを一瞬買おうかと思ったけど。

来年はSnapdragon 820を採用したAndroid端末は買ってるだろうし、家のMac Miniもビルドが遅いのでそろそろ買い換え取きかも。あとLaptopもDELLのXPS13かSurface Bookくらいを買いそうな予感。

Web Assembly

Firefox Developer Conference 2015 in Tokyoがあったのだけど、そこでemscriptenとWeb Assemblyの話してきた。



Web Assemblyは個人的に今一番ホットな話なんだけど、このイベントの矢倉さんのセッションでもViewSource ConferenceでLukeが話した内容を元に2ページほど触れられている。

あと、先週のBlinkOnでもセッションあったので、これもみるべし。

今のところ、s-expreesionベースのフォーマットでみんな実装実験やってるし、clang/LLVMも:sunfishがバックエンド実装やってる。LLVMについてはasm.jsからのwasmトランスレーターで間に合うからステーブル化の最初のMUSTなことではないけど。ちなみにJavaScripteCore/WebKitはすでに実装テストしてて、CPP->JSにしたものとCPP->JS->WASMにしたもので比較すると2倍の速度で動くっていう結果が出てる。

セッション終わったあと、Jxckさんと話しをしててWeb APIを直接触りたいよねって話をしてたんだけど、なんかAPIは作る話にはなってるっぽい(けど、これは最初のゴールには含まれない)。

基本ゲーム (canvasとWebGLは使いたいよね) が最初のターゲットかなと。

Gecko cross build using docker

Firefox 4のリリースがされたらへんから10くらいにかけてコツコツとLinuxのクロスビルド環境の整備をしてた。その結果クロスビルド環境においては、DebianのMultiarch/HOWTOで書かれているやり方で環境構築できるようにしている。

FirefoxというかGeckoを組み込みで使いたいなんて話が仕事柄たまに来るんだけど、環境の作り方を説明するのが面倒すぎるし、自分で検証用にVMWareのクロス環境を持つのもバカバカしい (OSのアップグレードのたびにテストしてた) のでDockerを使ったコンテナに移行した。

https://hub.docker.com/r/wontfix/gecko-armhf-dev/ (armhf用)

dockerで以下のようにイメージを実行すれば、必要なライブラリは入っているので、mercurialでcloneするなりtarballを持ってきて、.mozconfigを書けばarmhfのビルドができる。

docker pull wontfix/gecko-armhf-dev
docker run -it wontfix/gecko-armhf-dev

Dockerfileを見ればわかるけど、クロス用のライブラリをインストールするとき (特にlibgtk2.0-dev)、--no-install-recommendsをつけないとライブラリがコンフリクトしてしまうものあるので、注意が必要みたい。(というかlibgtk2.0-devのパッケージングの際、RecommendにPythonが入ってるんだけど、それはおそらくPython:anyにすべきなんじゃないかなと)

WebCompat

MozillaはFirefoxやFirefox OSの開発以外にもいろんなことをしてが、Mozilla社内にはWebCompat Teamってのがある。

何をしているかを説明すると、Firefoxや他のブラウザで表示されないページを解析して、なぜ表示されないのかを調べ、それを製品やWebの標準に活かすことをやってる。場合によってはコンテンツ制作元・会社へ問い合わせをして、具体的な修正方法を提示するってこともする。

今年になって彼らはアジア圏のモバイルWebサイトを集中的にみてる。具体的には中国と日本。日本も見てるけど、日本語がわからない人が見てるんじゃないのって思う人はいるかもしれないけど、チームメンバーの一人は日本に住んでいるので日本の事情もよく知ってる

日本のサイトにおいて彼らはTOP100+のモバイルサイトをすべてチェックして、大体の傾向があるそうだ。

• CSS flexboxはwebkitプレフィックスを使った古い形式のものが未だに使われている (= Web標準を利用していない)
  
• CSS xxx (いろいろ) はwebkitプレフィックスを使った古い形式のまま未だに使われている (= Web標準を利用していない)
  
• ユーザーエージェント文字列にWebKit的なのがないとモバイルと見なさない。またAndroidという文字だけでもモバイルとみなしてない。でもAndroid 4.0のようにバージョン番号を含めるとそれが改善するサイトが結構存在するらしい
  
• 使われているライブラリがWebKitでしか動かない (CSS TransformがWebKitプレフィックスがないと動作しない。JavaScriptから触る場合も含めて)
  

Mozillaの解析結果で言えば、Microsoft Edgeのユーザーエージェントの件は、現状のモバイルWebでどうしたら適格に表示できるようにするかということを考えればいたしかたないことだと思う。これをバカにする人たちは現状のモバイルWebを理解していないか、SafariとChromeだけで動けばいいサイトを作るひとのどちらかだ。そういう人たちに限って、Internet Explorer 6でしか動かないサイトを作ってた人たちなんじゃないかな

でもMozillaのやりかたで言えば、Microsoft Edgeのやり方よりももっとすべきことがあると思う

Mozillaで言えば、こういうことをまず最初にやる

1. 表示できないサイトを調査 (それ用に検出ツールもある)
   
2. 原因を特定し、サイトのオーナー (要はその会社) にコンタクト
   
3. コンタクト可能であれば、修正方法も含めて提供・アドバイス
   

MozillaはモバイルWebにおいて強力なシェアを持った会社ではないので、僕らの言うことなんて聞いてくれない・無視する会社も存在する。もちろんコンタクトをとったところ、ちゃんと直してくれるところもあるけどね！。どうしても直してくれない場合にはいくつかメカニズムを用意してる

UserAgentの書き換え

ユーザーエージェントを強制的に別の文字列にすることでモバイルページとして認識させる。https://dxr.mozilla.org/mozilla-central/source/mobile/android/app/ua-update.json.inにリストがある

CSS unprefixing service

webkitプレフィックスとかを強制的に外す。https://dxr.mozilla.org/mozilla-central/source/caps/nsPrincipal.cpp#501ここらへんがそのホワイトリスト。

ということもやって、モバイルWebページに対しても表示改善を行っている。ここ数か月でFirefox for Androidを使った時にページ表示が改善しているはず。

こんなことをブラウザベンダがやらなくてもWeb開発者が標準に即したページを作ってくれればいいんだけど、残念ながらそういうことにはなっていない。プレフィックスというデザインがよくなかったという話は数年前にしていたけど、いまだにこれが現状だ。

またWeb Compatibilityって考えかたはシェアが大きい会社であればあるほど言わない。それは昔のMicrosoftを見てればそうだし、今のシェアの高い会社を見れば、そんな感じ。MozillaもMozilla.orgになってからはここを重要視しているし、各ブラウザの互換性向上には各ベンダーが投資してほしいなと個人では思ってる

最後に、報告先として彼らはサイトを持っているので、https://webcompat.com/ に報告してもらえると助かる。ここはFirefox以外にEdgeの件も報告してもらって構わない。Web全体のComaptibility向上が目的なので。

あ、これらの話はもう少しデータ付きで会社のブログに書くべきだなと今思った

FCC 740 フォーム

スマートフォンをアメリカに送る必要があったのでFedexで送ったのだけど、税関でFCC 740フォームが必要と連絡があったのでその時のメモ。

日本で技適があるようにアメリカでもFCCで電波規制が存在してる。そのためスマートフォンなどを送るとこのフォームを書く必要があるそうだ。

• Device Model: 日本での型番
  
• Trade Name: 日本での商品名
  
• FCC ID: FCCの認可番号。日本のスマートフォンはFCCの認可を通している場合がほとんどなので、その番号を調べて記入
  
• Description of Equipment: smartphoneとか書く
  
• Manufacturer’s Name and Address: 製造した会社。および住所。ソニーだったらソニーの住所
  
• Consignee’s Name and Address: 受け取り人
  
• Importer’s Name and Address: 輸入したのが受け取り人であれば、Same as consigneeって書く。だいたいそれでOK
  
• Printed or Typed Name of Importer or Consignee: 発送者または受け取り人。ようは自分の名前を書いとく
  

あとPart 2のところは該当するものにチェック。今回は売り物じゃないので7.にチェック

こんな感じでフォームを埋めたら税関通った。

Adobeが行っている各ブラウザへのコントリビューション

Microsoft EdgeでAdobeがコードの貢献をしたという話があったのだけど、これを見て、EdgeはAdobe、Microsoft連合だ思っている人が多いみたいなので、Adobeが各ベンダに対してやってることを書こうかと。

まず、彼らはSVGとかCSSとかの仕様への貢献をずっと行っていて、SVGの場合ではSVGWGのFace to Faceミーティングの場所を毎年貸し出したりしてる（シアトルのオフィスがそれ）。

そもそもAdobe自体はいろいろとWebに対しても行っているのだけど、彼らにとって、仕様の貢献を行っていても実際ブラウザベンダが実装しない限り絵に書いた餅でしかないので、彼らが必要と思っている(関わっている)仕様に関しては実装まで手を出しているってのがここ数年の状況だ。

Geckoサイドでいうと、CSS Filtersは彼らの貢献なしでは実装が進まなかったというか、その部分に関しては彼らがコード書いている。

WebKitだとCSS ExclusionsとかCSS FiltersとかCSS Regionsらへんが絡んでる。(Feature FlagをAppleがOnにしないとSafariとかで使えないけどね)

BlinkだとBlendingとかCSS Sharpesとか

このようにAdobeという会社は各ベンダーのエンジンに対してコードを書いてたりする。自分たちが必要だから仕様を策定しているのだから、そりゃ当然実装にも手を出すよねってこと。Microsoftの件はそれがOSSでなかったとしても手を出し始めたということだね。

基本的にAdobeのブログとかで触れられるCSSとかの仕様・技術の話は彼らが仕様策定に絡んでいたり、実装を行っていたりするものなので、そういう視点でブログを読むとより楽しく感じる思う。

ちなみにAdobeのMozillaへの貢献としてTamarinというJITエンジンの話を出す人がいるけど、あれパフォーマンス出なくてGeckoへ統合されなかったものなんだよね。しかもその後、現Mozilla CTOのGalがほぼ一人で書いたTracing JITのほうが遥かに速かったというオチまでついた。(JavaVMへのTracing JITの実装を大学でやってた時にBrendanに引きぬかれたのがMozillaに来たきっかけだった記憶がある）

ARMv8 におけるAESアクセラレータ

CPUが自分自身で暗合用命令を持つのは、x86だとVIAのC7くらいが最初だったと思うけど、ARMもARMv8はCPU自体に持つことになった (TIのOMAPとかはDSPにアクセラレータが入ってた記憶があるけど)。aarh64でもコンパイル時にオプションが必要なので標準命令に入ってないっぽいからIP的にはオプションなのかも。

IntelでもNehalemで同様にAES用の命令が追加されていて、既にOpenSSLとかNSSとかLinuxカーネルとかで既に使われてる。

ARMv8ではAES用、SHA1用、SHA2用の命令が追加されているのだけど、今日はAESの話。

まず最初にAESの暗号化のアルゴリズムを簡単に説明すると、

AddRoundKey
for i = 1 to 10
  ShiftRows
  SubBytes
  MixColumns
  AddRoundKey
ShiftRows
SubBytes
AddRoundKey

と表せる。ARMv8の場合は、このアルゴリズムをいくつかの専用命令で実装できるようになった。

aeseは、AESのアルゴリズムの内以下の命令を実行する。

AddRoundKey
ShiftRows
SubBytes

aesmcは、AESのアルゴリズムの内以下の命令を実行する。

MixColumns

同様に復元化はaesdとaesimcで可能。

このようにこの2つの命令を使うことで、AESの暗号化の実装が可能になってる。すなわち暗号化の際にはaeseとaesmcでRound処理をして最後のラウンドだけaeseとveor使って実装することができる。AES 128bitの暗号化をARMv8で実装すると (AddRoundKeyはXORなので)

for i = 1 to 10
  aese
  aesmc
aese
veor

ということになる。なおこれらは最近のチップ(Apple A7やNVIDIA Denver、Cortex-A57/53ベースのもの)であれば32ビットモード(aarch32)であっても利用可能。

サポートされているかどうかについてはLinuxであれば、/proc/cpuinfoを見れば、Featuresにaesがあるかどうかで確認できる。

Processor       : NVIDIA Denver 1.0 rev 0 (aarch64)
processor       : 0
processor       : 1
Features        : fp asimd aes pmull sha1 sha2 crc32
CPU implementer : 0x4e
CPU architecture: AArch64
CPU variant     : 0x0
CPU part        : 0x000
CPU revision    : 0

Hardware        : Flounder
Revision        : 0000
Serial          : 0000000000000000
MTS version     : 33410787

また参考としてx86のAES専用命令の場合は、aesencとaesenclastを使って暗号化、aesdecとaesdeclastを使って復元化する。すなわち、x86でのAES 128bitの暗号化は、

AddRoundKey
for i = 1 to 10
  aesenc
aesenclast

ということ。ARMとIntelで実装アイデアが違うのは興味深い。

Vertical Layout on IME Sample

Microsoft Word on Windows 8.1 and Microsoft IME

Microsoft Word on Windows 8.1 and Microsoft Pinyin

Firefox 40 on Windows 8.1 and Microsoft IME

Firefox 40 on OSX 10.10 Yosemite and Apple Input Method

Python本体のしょうもないバグを直したのでその時のメモ

Servoというプロダクトでmachというビルドツールを使ってるのだが、こいつがPythonで書いてある。machをMSYS2で実行するとなんかPython本体がクラッシュするので軽く調べてみると、Python内部でエラー時の処理が間違ってて、ctypes経由でPythonがクラッシュするという現象らしいということがわかった。

そういうしょっぱいバグをレポート (http://bugs.python.org/issue23338) したんだけど、その際の手順。


バグをレポート
Issue Tracker (http://bugs.python.org/)にバグを登録する。

"Create New" を選択して、タイトルなどいろいろ書きこむ。

なお、パッチを書く場合は、https://docs.python.org/devguide/triaging.html#mercurial-repository に書かれているように、各ブランチ毎書くことも可能

最近のプロダクトだとレビュープロセス用の操作があったりするのだけど、どうもPythonの場合は存在しないみたい。そのため、バグを登録するだけらしい。

こういうしょぼいバグでもだいたい2か月くらいでハンドルされるので、バグを登録してもすぐ直してくれるってことではない感じだね。それは仕方ないけど。

Tizenを搭載したSamsung Z1を購入したんでその話

新しいOSを入れた端末ってのは当然欲しくなるし、どういうものが使ってみたいのでインドで発売になったSamsung Z1をebay経由で購入した。送料込みで約18,000円弱。

大きさ自体はいPhone5sよりも若干大きい程度でXPEDIA　Z1ｆよりも小さい。作りは安い感じではあるんだど、持ってみると手に収まる感じでまぁまぁいい。というか、このくらいのサイズのスマフォがほしいんで個人的にはサイズ感は好みです。

まず最初にスクリーンショットを撮るためには、Tizen SDKに入っている sdb コマンドを利用する必要がある。本体の操作ではスクリーンショットの取得はできないらしい。

Z1のUIは英語（UK)とインドの各言語のみ選択可能で日本語は入ってない。ただし日本語フォントが入っているので日本のサイトは普通に表示可能。日本のサイトはドコモがいろいろ行っていた関係で大手サイトの何割かはTizenのユーザーエージェントを識別してモバイルサイトを表示するようになっているので、例えばインプレスのサイトなんかはモバイルサイトが表示される。

Tizenではアプリストアは2種類存在して、Web App StoreとTizen Store。Web App Storeはただ単にQuick Access Listに追加されるだけのもので、Tizen Storeはちゃんとアプリとして入れられるもの。なお、Tizen StoreにはOpera Miniがあった。

また、Web ブラウザのUser-Agentは以下の通り。

Mozilla/5.0 (Linuxl Tizen 2.3; SAMSuNG SM-Z130H) AppleWekKit/537.3 (KHTML, like Gecko) SamsungBrowser/1.0 Mobile Safari/537.3

また、WebKitだけあって、JavaScriptの昔のベンチマーク、SunSpiderは速い。比較対象は、auのFx0ね。(Cortex-A7ってところは一緒)

あとアプリはインドらしくクリケットのアプリが入ってるくらいかな？

Tizen OS 2.3が思ったよりも出来がいいんで、これが100ドルであればいいんじゃないかと思うよ。

Microsoft Location Serviceの動作

とある諸事象でMicrosoftのLocation APIの動作について調べてた。ちなみにBingのAPIとは別らしい。

Windows 8以降のLocation APIは、Windows Phoneと同じようにWiFi情報を元にして位置情報を決定することができる。Orionという呼ばれる位置情報サーバーにSOAPでリクエストを投げるとデータが返ってくる仕組みだ。2011年から稼働しているのにSOAPでAPIにアクセスする。

これだったらGoogleとかの位置情報サービスと変わらないのだけど、Windows 8以降のLocation Providerはサーバーから取ってきたデータを内部データベース (\ProgramData\Microsoft\Windows\LocationProvider\LocationCache.dat) にキャッシュしておく。そのためLocation APIを呼び出しても常にサーバーへ問合せはされない仕組みになってる。これはただのキャッシュというよりも、ある程度な範囲 (300m? くらい) の位置情報データベースを内部でも構築するような仕組みになっているため、インターネットの接続が切れた後であっても自分の位置が変更 (=WiFiのブロードキャストリストやシグナル情報が変更) になれば、Location APIが位置情報を推測して返すことが可能になってる (どうもドライバ内で計算してるっぽい)。

実際のデータに関しては、inference.location.live.netというSOAPサーバーにHTTPSで接続してデータを取得してる。そのためこのサイトをブロックしてしまえばおそらく位置情報の取得ができなくなる。

この位置情報サービスのデータについては、Windows Phoneのサイト (http://www.windowsphone.com/ja-JP/how-to/wp7/web/location-and-my-privacy) を見るとデータポリシーとかは書いてある。いろんな情報をまとめると、Windows 8でも同じサーバーにアクセスしてるのはわかってる (でもAPIは微妙に違うみたい)。

このページを読む限りそもそもデータ収集にWindows Phoneも使われていたそうなので、Microsoftの位置情報サービスは日本での精度に期待できないということはよくわかったし、_nomapとSSIDにつけても無視するということもよくわかった (https://www.windowsphone.com/en-us/support/location-block-listで申請しろってことらしい)。

そのデータ収集だけど、どうもBing Map版ストリートビュー車も使ってるということらしいけど、日本ではそのサービスがされていないので日本での情報量が少ないこともよくわかるオチでした。

Firefox Nightlyで位置情報プロバイダがGoogleからMozillaに変更になった

ブラウザ内で位置情報を取得する際、FirefoxではGeoIPとWiFi情報から位置情報を決定している。従来のFirefoxではGoogleの位置情報APIを利用していたのだが、先週末のFirefox NightlyからGoogleの位置情報APIではなくて、Mozilla自身の位置情報APIを使うように変わった。

Mozillaの位置情報サービスはMozilla Location Servicesという名前で開発を行っていて、GoogleのAPI互換かつ、サーバーなどのソース、収集されたデータさえも公開されている。(細かい話は以前書いたエントリを参照のこと。)

ここで参照されるデータというのは、以下のアプリで収集されたものがベースになっている。

• Mozilla Stumbler
• Firefox for Android (Mozilla 位置情報サービスへのデータ送信を有効にしている場合)

Firefox for Androidで位置情報データがMozillaへ送信する場合は限定的な条件がついている。それはGeo Location APIを利用した際にGPSベースで位置を取得した場合のみだけになっている。そのため、まとまった量の位置情報のデータを送るためにはMozilla Stumblerを使うのが現状ではベスト。

これらのデータに関しては一年前からコツコツデータ収集をしてきたので、東京の都心に関してはデータの密度は高くはなっている。

ただ、これだと場所によってはデータの品質に問題があるので、Windows版とOSX版のみ別のプロバイダを使うオプションが存在してる。

Microsoft Location API
Windows版上でabout:configでgeo.provider.ms-windows-locationをtrueにすると、代わりにMicrosoftの位置情報サービスを使うようになる (Windows 7以降)。すなわち位置情報についてはInternet Explorerと同様の品質になる。

Core Location API
OSX版上でabout:configでgeo.provider.use_corelocationをtrueにすると、代わりにAppleの位置情報サービスを使うようになる。(OSX 10.8以降だったはず)。すなわち位置情報についてはSafariと同様の品質になる。

Firefoxの正式版のころにはいろいろ変わっていると思うけど、今の開発版ではこんな感じになってる。

XHR({mozSystem: true})がマジで使えない件

XHR (XMLHttpRequest) 自体は、CORS (Cross-Origin Resource Sharing) をサポートしないと自分のドメイン以外へのXHRのリクエストに対してレスポンスヘッダーとかの値を取ることはできない。そのためFirefox OSではmozSystemというオプションを用意して、CORS対象でないサイトへのリクエストであってもXHRが使えるようにはなっている (SystemXHRの権限を与える必要あり)。

また、XHRは302などのリダイレクションに対しては、自動でリダイレクト処理を行う。

CORSが使える環境においては、XHR.withCredentials = true にするとCookieとかも扱えるようになる。CORSじゃない環境 (mozSystem:true) の時はCookieとかは自動的には送らない。

XHRはこんな感じで動作するだが、この前提において、こんなケースにぶち当たった。

POST /abc
Host: example.com
Content-Type: application/x-www-form-urlencoded
Cookie: SESSIONID=ABC

というリクエストをとあるサーバーに投げると

302 redirect HTTP/1.1
Location: https://example.com/def
Set-Cookie: cookie=ABC <----(A)

と返してくるから、XHRは自動的にリダイレクト処理をするので、

GET /def
Host: example.com
Cookie: SESSIONID=ABC

と送るわけだ。ここで重要なのは (A) でSet-Cookieした値は、リダイレクト後のGETには入らないということ (mozSystem: trueだから)。そのCookieがWebサーバー側は必要としてたようで、以下のように返してきた。

404 Not Found HTTP/1.1
Host: example.com

(A) の値さえ取得できれば、自分でリダイレクト処理をすればいいんだけど、当然ここから、(A) を取得する方法なんて存在しないようで。。。XHRでリダイレクトを止めたいという話はstackoverflowでもwell-knownな質問で、答えは「不可能」。

一瞬mozTCPSocketを使って簡易HTTPクライアントを作ろうかと思ったけど、そもそもHTTPSなサイトなんだよねということで諦めた。このXHR({mozSystem: true})自体はちょっと凝ったことはできないよねってこと。そもそもFetch APIが来てればこんな悩みもしなかったのにって話でした。

(後でmozSystem:trueの場合でいいからリダイレクトを止めるオプション作りやがれバグはファイルしておくが)

Micosoft Wireless Display Adapterを買った

ポートランドのMSストアにはなかったんだけど、Miracastを試したくなってebayで購入。

以下感想

• Windows 8.1のラップトップ (DELL XPS12) は簡単につながる。Surfaceも。
• 若干遅延があるけど、気にならないレベル
• Store Appとして設定アプリがあるのでこれを入れればファームアップデートとか行える
• Nexus 5もMiracastでつながる。でもたまに表示がおかしくなる。表示がおかしくなったら、再度再接続すれば直る
• XPEDIA Z1fのMiracastだと接続中のままで接続が完了しない
• Nexus 9がMiracastサポートしてなかったということを気付く

という感じ。

ルビ on Firefox

ちょっと前縦書きの話を書いたので、次はルビの話でも。日本語で残さないとMozillaはやる気がないとか、変なこと言う人が日本には多いしね。

ルビについてもFirefoxでは開発チーム的にはは実装途中になっている。ルビの実装状況をみたいのであれば、Nightlyを使ってabout:configでlayout.css.ruby.enabledをtrueにすれば使えるよ。

例えば、こんな感じのHTMLは、

<div><ruby><rb>🍛</rb><rt>咖喱</rt></ruby></div>

以下の感じに描画される。

もちろん、以下のような感じでwriting-modeを設定すれば、

<div style="writing-mode: vertical-lr;">
<ruby><rb>🍛</rb><rt>咖喱</rt></ruby>
</div>

writing-modeが適用された状態で表示される。

CSS Rubyはまだほとんど実装されていないのだけど、デフォルト値のruby-align: space-aroundだけ動作する。

このバグをウォッチしているといろんなバグの修正がわかるはず。

今のところそんな感じ。自分が実装をやってないからどのバージョンでデフォルト有効になるかは知らないけど、2015年中には有効になると思うよ。

2014年に買ってしまったもの

ガジェットで覚えてるものだけ。

Microsoft Natural Ergonomic Keyboard 4000
会社で使ってたNatual Keyboard Elite (USBのみのOEM版というレア仕様) のキーボードが壊れてしまったので購入。ちなみに初代Natural Keyboardは家で未だに使ってます。

ずっと使ってきただけあって、一番馴染むのがNatural Keyboardという自分にとっては、未だにこの配列のキーボードを出してくれるMicrosoftには感謝してる。SpaceSaverやHHKとかを使った結果、これが一番なのでどうしようもないですね。

ちなみに買ったのはebay経由でUS配列のほう。日本でJIS配列を発売するようになったおかげでUS配列が日本で買いづらくなったのはホント勘弁してほしい。

Microsoft Sculpt Ergonomic Mouse
最近ずっとLogitechユーザーだったんだけど、MX-Rの後継機が存在しない & MX-Rのバッテリがついに死んだということで購入。MX-Rは発売日にヨドバシで買ったものだから、愛着あったんだけどね。

電池の蓋がすぐ外れてしまうという問題と会社の机と相性が悪い以外は、満足してる。マウスパッド使えばいいだけだし。



Flame
Firefox OSの開発用端末。本当に買えるのか試したら、買えてしまったヤツ。もう国内で売ってないけど。海外のはAsaに聞けば買えるかもね。

こいつに関してはいろんな話がありましたが、ノーコメントです。

メインのスマフォが壊れた時に、これで何日間か生きてましたが、えっと普段使いにはパフォーマンス足りないっすねって。アプリの問題はLINE (スタンプを新規で買えないとかLINE絵文字使えないって話はあるが) とTwitterとWeb Browserと日本語IMが使えれば生きていけるってのを確認できたのはよかったです。

ASUS MeMO Pad 7
Intel入ってるAndroidで安価なものを探してたところ、2万しない価格で売ってたので買いました。主にIntel Androidのデバッグ用途。GPUドライバの出来がよくなくて、Open GL叩きまくるとハードウェアごと落ちるのが玉に傷。最近のファームでだいぶ直ってるけど。

この世代のatomは性能良くなってるんで、VAIO PがこのCPUで出れば買うのにねって (元VAIO Pユーザー)



Google Nexus 9
タブレットには一切興味がないのだけど、64bit ARMで動くAndroidということで買いました。nVidiaの新規設計のaarch64 CPUかーと思ってただけだったんだけど、リリース直前になってコードモーフィング使って動かしているという情報を耳にして、このトランスメタが過去にやってたことをnVidiaがやるってことで、テンション上がりまくり。

いろんなデータとってみたけど、aarch32モードはCortex-A15と同性能レベルでaarch64じゃないと速くないです。あとAESのネイティブ命令速っ。

でも主の用途は、Android/aarch64の評価用 + 開発用途なだけ。



au Fx0
Mozillaで働いてるんだし、ドックフードしないとねということで。自分のMS時代からのポリシー(というかあの会社の文化でもあるけど)で、エンジニアであるのであれば、ドックフードを食べなきゃいけない(要は自分たちで作ってるものは、自分で使って試せということ)というのがあってね。あの会社の恐ろしいところは社内のプロダクションに開発途中版 (内部デプロイ用のバージョンであって、外にでてるベータのクオリティにも満たさないもの)を投入してくるんで、社内で社内で業務が止まることがたまにあるというところ。当然そうなると開発チームが緊急修正行うことに。。。話がそれた。

これに関しては、書けない話は大量にありますが、えーっと、LGのソフトウェアチームは優秀でしたよ。ハードウェアメーカーもソフトウェアチームはグローバルに持たないといかんなーと思いました。これのソフトウェアに関しては、今まで出たFirefox OS Phoneの中で一番素の状態とはかけ離れてるんじゃないかなっ？


来年はというと、素のLinux (Fedoraらへん) が動くaarch64ボードは絶対買ってるだろうねというところかな？