読者です 読者をやめる 読者になる 読者になる

Snippets

対抗して作ってみた。

ALPを支えられなかった技術(2)

ALPを支えられなかった技術(0) - Snippets の続きです。

ALP第二期 - LIMOを狙って

便宜的に分けた ALPの第二期は LiMo を巡る動きとなります。

とはいうものの、この期の分け方は適当で、実際には複数のプロジェクトが同時に走っていて、 GTkをつかった第一期のプロジェクトと LiMoむけの第二期は社内でも平行して走っていました。 自分は前者のプロジェクトにメインで関わっていたので、LiMoむけの作業はちょっと手伝っただけです。

というわけでどちらかと言うと LiMo関係については担当者の愚痴やらで伝え聞いた部分が多いので ネガティブな印象になってることは否めません。その点はなるべく割り引いて書くようにしますが。

LiMoとは

Wikipediaにあるとおり、ハンドセットメーカー 4社とキャリア2社が連携して携帯用プラットフォームを作ろう、 というものでした。 大同団結といえばいいけど、呉越同舟というか同床異夢な感は当時としても否めませんでした。 具体的になにを作ってなにを達成しようとしてたのか、が末端エンジニアにはよくみえず、 やりにくいなあ、ということは感じたものです。

やりたいこととしては、Nokiaやら Microsoftやら (まだ出荷されてなかったけど) AndroidiPhoneに市場を席巻されないようにしよう、という後ろ向きの目標のようなものは感じられました。 ただ、いままで別々にソフトを開発してきて、違う市場に対応してきた各社があつまって 意味のあるものを作り上げられるようには見えませんでした。

LiMoは APIでしかない

今から考えてみると LiMoとは TRON、もしくは POSIXのようなものだったのでしょう。 あくまで APIを一致させ、その上で共通アプリケーションを作り上げられるという。 APIを一致させておけば、アプリケーションとミドルウェアの組み合わせは選べるという。 というわけで、ACCESSが ALPをベースにして作り上げたものは「リファレンス実装」という 位置づけになります。

とはいうものの、世の中はそんな絵空事どおりに動きません。 APIだけでは依存関係を解決することはできず、そこから派生したエコシステムやらがひっついて 回るのが必定です。 WindowsPOSIXサブシステムがあったって、 世に多く普及している Linuxやらのアプリケーションは動きません。

ましてや、まだアプリケーションもない LiMoのことです。 ハンドセットメーカー各社に、共通の LiMoのAPIだけをつかってアプリケーションを書く モチベーションがあったか疑問です。 また、それ以外のプレイヤーがアプリケーションを書いて流通させるチャンスがあったかも よくわかりません。

ACCESSの作ったリファレンス実装

ACCESSはそのような動きの中で、ALPと、すでにあたった DocomoLinuxプラットフォームを 合わせてリファレンス実装をつくることになりました。 ここらへん、ACCESS以外の各社の IPに関することにもなるので、いろいろ大変だった、 とごまかさせてください。 ただ、いろいろと NECの人などからガラケーガラケーたらしめる作り込みについて 話を聞けたのは面白かったです。

LiMoのまとめ

個人的見解としては、LiMoは ALPの中では傍流、DoCoMoにお付き合いするための プロジェクトという理解です。 もちろん、そこから LiMoがひろがって各社でつかわれることをもくろんでいたのかもしれませんが、 そこにはいろいろと政治的なとりひきをしなければならなかったでしょう。 個人的にはあまりお付き合いをしたくない分野です。

というわけで技術的な話は今回はあまりありませんでしたが、 次回、Monolithのはなしまでお待ち下さい。

ALPを支えられなかった技術(1)

ALPを支えられなかった技術(0) - Snippets の続き、というか Activityについて突っ込まれたので補遺的に。

Activityと画面遷移

ALPもやはり Androidと同じように Activityの遷移によって画面を構成する、というものになっていました。 これは、Palmからの共通進化といっていいでしょう。 Backボタンを付けてスタック的な動作を可能にしたのも共通です。 Palmにはない機能ですが、Webの Historyから両方共おなじものを学び取ったような気がします。

ただ、Intentのような動的な Activityの解決はありませんでした。 連携先として呼び出される Activityは静的に決まっていました。 ここは、SDKを公開してアプリケーションを作ってもらう体制になっていなかったせいでしょうか。 先に書いたように、アイディアとしてはあったものの未来のものとして先送りでした。

Activityの突然死に対する対策は、呼び出される Activityのパターンが決まっているため それほど洗練されてはいませんでした。 一般的なコールバックとかはできておらず、それぞれのアプリが頑張っていたような気がします。 一つのアプリに関して複数の Activityのインスタンスができた場合どうするのか、とかは 恥ずかしながらボロボロだった気がします。

ALPを支えられなかった技術(0)

歴史だ! 読んで、泣け!

Androidを支える技術」の著者に煽られたので書いてます。 もう終わった過去の技術の話ですが、エイプリルフールの余興にでもなれば、と。

ALPとは何か

Wikipediaにある ように、日本の ACCESS社が USの PalmSource社を買収して作り始めたスマートフォン OS (or ミドルウェア) です。 とはいうものの、一度も出荷されたことがないので外部の人はちゃんとしたことはわからず、Wikipediaに書いてあることも「違うなあ」という感じです。

煽ってきた有野くんも ACCESSに在籍したとはいえ、ALP開発のころにはすでに MS帝国の人になっていたので、そこら辺の事情を知りたくて煽ってきたのもあるでしょう。

ALPはひとつのプラットフォームのように言われますが、実をいうと市場の変化に対応する 形で融通無碍に変わってます。 2006年の開発開始から 2010年の開発中止までの間に随分とターゲット、 そして使う技術も変わっています。

そこでここでは便宜的に ALPを 3期に分けたいと思います。

ALP第1期は、Palm臭をいかしつつも、DoCoMoとかに売り込めないか、と作業していた頃です。 iPhoneも発売されておらずのどかな時期です。

ALP第2期は、2008年ごろ、もっと DoCoMoにすりより、 LIMO として活路を探っていた頃です。 なんというか、いろいろ政治的な動きがうんざりする頃でした。

ALP第3期は、2009年、起死回生の手を探り Emblazeというイスラエルの会社と Monolithというデバイスを作っていた頃です。 無茶なことを言ってくる会社ではありましたが、技術的には面白かった頃です。

ここらへん、厳密に区別があるわけではありません。 また、当時の資料も私の手元には残っていないので記憶に頼って書いてます。 間違いがあったらもうしわけありません、といいつつ書いていきます。

ALPのはじまり

ALPの開発が始まったのは 2006年、iPhoneAndroidも世に出ていない頃です。各社が組み込み OSの上に独自に作り上げた Feature Phoneが花盛りだけど、SymbianWindows Mobileなどがその先をにらみつつ小競り合いをしてた頃です。

もちろん ALPもその小競り合いに加わろうというプラットフォームだったのは間違いありません。 小競り合いを勝つための武器の一つが、買収によって手に入れた PalmSource (およびその一部となっていた BeOS) のユーザベースと技術です。 もう一つとして iモード時代に築いた DoCoMoとの関係というのもありましたが、これが吉と出たかはよくわからないところです。

PalmSourceのもっていたもの

PalmSourceは2000年前後には PDAおよび携帯電話用 OS、PalmOSを出荷し時代の寵児でした。 ただ、その後の発展に伸び悩んでました。 マルチメディア、マルチタスク系の機能を伸ばそうと (あの Jobsに負け Appleに買収されなかった) Beを買い取り、 Cobalt を 発表しましたが出荷には至りませんでした。

そうしてジリ貧感が漂っていたところに日本のよくわからん 組み込みソフトウェア会社に買われたわけです。

ジリ貧とは言え、BeOSから引き継いだ技術はいろいろ目につく物がありました。 まずは、Androidでも採用されている分散オブジェクト技術 Binder です。 組み込みOSからは発想が及ばないものでした。

また、Palm時代から培われた Usabilityに関する哲学 Zen of Palm も、 「Androidを支える技術」を読んだあとだと重要なものだったんだなあ、と思えます。 あとがき に 書いてあるような小さい画面での UIデザインについて最先端を走っていた会社ではあるので。

また、その延長線上で Intentや Activityという 技術についても検討されてました (Android以前に!)。

持っていたものではなく失ったもので言えば、 Dianne Hackboneという、後に Androidの開発の重要な部分をしめる開発者も PalmSourceにいたのですが、私が ALPに joinしたころにはもういませんでした。

第1期ALPが選んだ技術

第1期 ALPが選んだ技術はすごい特筆すべき者は実はありません。

まず、GUIは独自のものを作らず Gtkを使っていたあたりで 今から考えるとわかってない感がしますが、当時の技術者の意識としてはそんなもんです。 X11ではなく DirectFBという技術を使おうとしていたのが組込系ですが、 マルチプロセスのときの動作でいろいろと苦労して X11に戻った記憶があります。

あと、実は Binderを使うのは諦められました。 既存の Unix系の技術と相性が悪い、とかいう理由だったかと思います。 IPCは昔ながらの socketをつかってやる、ある意味融通の聞かない形式になりました。

プログラム言語は Cでガチガチに書きます。 Javaのようなミドルウェアを作り込むリソースはなかったのと、 速度が実用的だとは思われてなかったせいでした。 MIDPなどをサポートしたおまけ程度の Javaは視野に入れられてましたが。

今から振り返ってみれば、Androidとの共通点はいくつかあります。

  • Zygoteのように、予めライブラリをロードしておいたプロセスから folkするようになってた
  • アプリごとに uidを割り振ってセキュリティを確保してた
  • Linux Input Subsystemの多用

UI的には Palmを延長したようなものを目指しており、 もちろん flickなどは考えられてませんでした。

このような商品を PalmOneはじめ各社に売り込んでいましたが、残念ながら採用に 至るメーカはありませんでした。

そうこうしてるうちに iPhoneが出て (2007年)、Androidも出荷され (2008年) あわてることになります。

つづき

ちょっとここまで時間がかかったので公開します。 第2期以降はまた後日。

なんで勉強しなきゃいけないの?

雑に書く。

一般的に子供からよく問われるものとして「なんで勉強しなきゃいけないの?」というのがある。

正直、自分はこれに関する答えを持っていない。

自分の体験から言えば、理数系の科目は好きだからやっていただけで「勉強」とはちがう。もちろん、それは役に立っているとは思うがそれは結果論であり、役にたてようと思ってやったわけではないし、役に立ってないこともいっぱいある。

一方で「勉強」の害悪というのもある気もする。単に教わったことを鵜呑みにするような癖である。日本の教育の先生モデルでは起こりやすそうだ。更に訓練されると「学問」は「勉強」という言葉遊びの架空のゲームであり、学生の間だけ覚えていればいいものだという反応を身につけそう。もったいないものである。

そこから踏み出して外発的動機づけによる勉強はよくない、といってしまうとそれはやはり勇み足だろう。いやいやでも計算する癖をつければ日常でも計算はしてしまう。それは単純に検算とかのいみで役立つだろう

まあ、そういう意味で役に立つ部分もあるよね、ってことで一般的な答えになってしまう。あたりまえだ。

さらに言えば疑問の持ち方を変えて「この勉強は役に立つのか?」という個々の問題に変えて考えたほうがいいんだろうなあ。

教育業界的にはもうすこしメタレベルに「勉強するくせ」とかいうのはあるけど、これはこれで別の話になるので別に考えたい。

というわけで雑に考えたので散漫になってしまったが、とりあえず公開しとこう。

動物化したポストガラケー

友人が 「Androidを支える技術」という本を書いたので宣伝がてらうだうだ書いてみる。

gihyo.jp

本はすでに本屋に並んでいてそれなりに評判もいいようで、ちょっとだけ手伝った身としてはなにより。レビューに参加した組み込みおじさんには好評だったけど、一般に売るにはちょっとマニアックすぎるのじゃないかと心配していた。まあ文字通り「支える技術」という点ではまったく間違ってはないし。

森田氏は 死んでしまったOSたちへ – To Phantasien で Opinionatedだといってるけど、普段彼と話してるともっと opinionatedなので、わりと大衆受けを狙って抑えてるなあ、とか思ってしまった。まあ、そこらへんの読者層を鑑みた語り口のうまさというのは、自分にはないものなので。

今回の本というのは GUIを中心のテーマにおいて Androidの技術を解説する、というやや偏ったアプローチになっているが、それはストーリーテリングとして楽しい。X11や framebufferべた書きの組み込みのころに GUIを学んだ身としては、表面だけを見ててはわからない変化があるのね、というのを実感する。

そもそも、自分は UI周りは得意ではなく、それよりはネットワークとかメモリとかを考えていたい口だったので、不勉強だったのはある。でも彼の 60fpsを全面に押し出した解説は、携帯業界というのが、機能とか安定性とかではなく UIを全面に押し出したマーケットになってしまったのだなあ、ということを否応もなく実感させてくれる。iPhoneがそう変えてしまったのだし、それについていけなかったガラケーやら Symbianやら WindowsMobileやら ALPやらが死んだのは必然的なものだったのだと。

なめらかな UIがもたらす快感というものがほんとうに我々の生活にとっていいものだったのか、という疑問はこのエントリのタイトルが暗喩してたりはするのだけど、でもそこをクリアしないと人々の口の端にものぼらない、という現実を認識して努力するのが正しいモバイルエンジニアというものなのだ。

ちなみに死者の末席に加えさせて貰ったALPではあるが、そこらへんの変化に気づいて追いつこうとはしていたのではないか、と今更ながら弁護したい気持ちがわいてきた。のでそこら辺は「ALPを支えたかった技術」として書ければいいな。

エラーメッセージとメンタルモデル

メンタルモデルとは

ユーザが心のなかに描くモデル。単純に押せば動くとかそういうものの積み重ねでできているようなもの。

メンタルモデルの重要性を解く例として、エアコンでいかに速く部屋を冷やすか、という問題がある。

エアコンの温度調整は単に出力の強弱を制御するもの、というモデルを持っている場合、速く冷やすためにとにかく温度調整を低くすることになりがち。実際うちの嫁はそうする。

しかし正しいモデルを持っていれば、つまり温度調整はサーモスタットなりの温度センサと連携して、スイッチをオン・オフするだけだとわかれば、温度調整を低くしたって速く冷えるわけではないのはわかる。逆に冷えすぎるという弊害がある。

正しいモデルを持っていれば、単純な用途 (部屋の温度を最終的には快適に保つ) 以外の場合でも応用が効く、というわけだ。

エラーメッセージ

エラーのときの動作というのは、その典型に見える。ここから卑近な例になって Androidなどのスマフォで動くアプリケーションを考えよう。

たとえば、よくあるアプリは、ネットワークから最新データを取得して、キャッシュを更新して、それでユーザに提示する。しかし、ネットワークからのデータの取得に失敗した場合、どうするべきだろう?

そんなに新鮮さが必要が無いアプリだったらキャッシュを表示するだけで充分かもしれない。でもそんなときに「最新データの取得にしました」と表示していいのかしらん? ユーザは、このままアプリを使い続けていいのか心配になるかもしれない。関係ないエラーまで、ネットワークエラーのせいにされるかもしれない。人間の因果関係の推測なんて偽陽性だらけだ。

自分としての理想としては、アプリは適切なメンタルモデルを提示して伝え、それに基づいた症状をうまく示してやれば、ユーザもワークアラウンドの指針も立って双方ハッピーなのではないか、ということだった。

メンタルモデルを伝えられる?

といったところで、適切なメンタルモデルなんてあるのだろうか、というのが今の疑問。というか、自分の答えは出てて万人に適切なのなんてない。

ユーザといってもいろいろいて、スマフォ触り始めたおじいさんから、スマフォしか使ったことがない十代、簡単なコードは書けるプログラマとかいろいろある。そこらに共通なメンタルモデルを作るなんて傲慢じゃないか。まあ、実際はメジャーなユーザに向ければいいのかもしれないけど、うちのターゲットである高校生だってリテラシーには随分差がある。

それに、あまりに内部実装によったメンタルモデルだと、内部実装の変更の邪魔にもなる。予めキャッシュしておいたほうが多くの場合スムーズに動くのに、メンタルモデル的にはそこでデータをロードするなんてありえないみたいな。

というわけで、今となっては安定性をとにかく増して、最低限サポートに必要な情報だけをユーザに表示して、CSにお願いするしかない、という理解になりつつある。まあ、CSとのチャネル、フローはまだまだ改善の余地があるので、そっちに頑張ったほうがいいかなと。

以上、30分で書いた愚痴でした。

スタディサプリでたよ

スタディサプリでました。本当はリリースしたのは 1週間以上前なんだけど、一部の人だけが知るリリースみたいになって盛り上がりに欠けたり、直後に Ingressのイベントで忙しかったりしたのでいまさら日記書きます。

まとめとしては、まあちゃんとリリースできてよかったじゃん、という限り。ちょっと直前にバタバタしたけど、必要機能は揃って出た。

はっきりいって一人では難しかったと思うけど、夏に入ってくれた Engineerが優秀で、こぼれ球をうまく拾ってくれたりしたおかげでちゃんとできた。あそこで来てくれてありがたかった。

反省点として全体というと、製品に対する愛がまだ足りなかったかなあ、というところ。

特に、リクルートと一緒になって最初にやるプロジェクトとあって、前半ではお互いに遠慮してた感があった。後になって、向こうが重視してるところとか、べつにどうでもいいところとかわかってきたんだけど、その時点ではもうスコープ外になってる機能とかもあった。もったいない。

UI系も、もっとちゃんと見る時間を取るべきだった。前から言ってるように、ここらへんは自分は苦手なので後回しにしがち。最初の計画では、最後の1ヶ月は UIとかのチューンをしようね、っていってたのに最小限になるのはよくあることで。もっとデザイナーとコミュニケートできるようにならないと行けないなあ、という気分。でも、俺だけができても、他の Engineerに俺が翻訳して伝えるのじゃ面倒くさいので、共通言語化していかないといけないのかしらん。ハブになる人をつくらないように。難しそうではある。

ほかにもありますが、ごりごり改善していきますよ。という感じで。