Snippets

対抗して作ってみた。

自転車を盗まれた

人間というのは、何かがなくなった、もう出会えないという事実を処理するのが下手なのではないだろうか。 とくに、それが愛着のある人や物ならなおさらである。 自動的に、もう出会えないという悲しい事実を認めるのを避けるべく、深層心理が悪魔の証明を求めて悪あがきする。 諦められずに、もしかするとあそこにあるのかもしれない、またちょっとしたら帰ってくるかもしれないと希望する。 ストレスに耐えるための正常化バイアスが発動してるのだといえよう。

ということを話すのも、愛用していた自転車がなくなったからだ。 状況証拠的に言えば、盗まれたというのが正しいのだろう。 朝、会社に乗ってきて、駐輪場に留め、夜、乗って帰ろうとしたらなかった。

観測した事実はそれだけである。 もしかすると、駐輪場の管理会社が移動させたかもしれず、風にのって飛んでいったのかもしれず、 いやむしろ駐輪場に留めたというのも記憶違いかもしれない。 なかった、という事実も信じられず、その後10回ぐらいは見に行った。

いずれにしても希望は砕かれた。管理会社は移動させることはないと言い、強風は吹いておらず、 朝かぶってきたヘルメットだけは手元に残った。

自分は、ある程度理性的であると自認している人間ではあるので、盗まれたという結論を認めるのに吝かではない。 実際、もう警察には盗難届を出したし、ネタとして同僚には話した。 購入金額で言えば 20万円ほどになる、そこそこの価値のある自転車なので盗まれるのも無理もない。 逆に、ちゃんとそこを見抜いた自転車泥棒にはなかなかやるなとも思っている。

ただ盗まれた事実を認めると、自分の落ち度というのも認めねばならないことになる。 実際、結構人の出入りの多い駐輪場に、さほど頑丈でもないダイアル式のチェインロックをしただけで放置しておいたのだ。 防犯上の観点からはいくらでも改善の余地がある。 もっと、頑丈な鍵にすべきだったとか、ダイアル式ではなく鍵式の錠にすべきだったとか、防犯ブザーなどのテクノロジーもつけておくべきだったとか、 そもそもそんな高価な自転車を通勤に使うべきではなかったとか。

しかし、錠を頑丈にしとけばよかったのか、というのは内心疑問もある。 開かない錠はない。ただ、開くまでどの程度時間がかかるかだけだ。 もしかして、犯人は毎日そこに高価な自転車が停まっていることを把握してたのかもしれない。 だとしたら、頑丈な錠をつけていても、それに対抗するような道具をもってこられるだけの話かもしれない。

もちろん、通勤に高価な自転車を使わない、というのは一つの解だ。 しかし、せっかく買った自転車を乗る機会を減らしてしまうのはもったいない。 駅に向かう人々を横目に、春風に吹かれて颯爽と駆け抜けた日々が間違いだったと思うのはむなしすぎる。

というわけでうだうだ後悔したりする日々を過ごしているわけである。 最後には諦めなければいけないのはわかっているが、吹っ切るきっかけにならないかなあ、とここに書いて見る次第である。 慰めは喜んで頂戴する。

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

いろいろなエイプリルフールの企画とともにふと思い出したので、ALPを支えられなかった技術の続きを書きます。ほぼ一年間もおまたせして申し訳ありません。

一応、あらすじというか過去の話へのリンク:

ALP第三期 - Monolith

さて、やっと Monolithの話が始まります。 Monolithというのはコードネームで、表向きは Emblaze ELSE といっていました。 とりあえず、MWCで発表したときのデモがあるので御覧ください。


MWC - The First Else cell phone brings a unique interface

今みてもそこそこおもしろいUIだと思います。 現在の、マトリックス状にアイコンが並ぶのとは全く違うスマフォの UIを構築しようとしているのがわかります。

この時は 2009年、すでに iPhoneも 3GSが出ており、日本でもソフトバンクが大々的に売り出していたころでした。 のっぺりしたFeaturePhoneの延長線のUIではなく、ヌルヌルしたUIで Appleを殴りに行くぞという気概は見ていただけるでしょうか。 ELSE、また別のスマートフォンという名前の示すとおりです。

ほかに engadgetの記事も見つけたのでリンクを張っておきます。そこそこ期待しつつも、パチモンなんじゃないかと訝しんでいるのが読んでとれます。

イスラエルの Emblaze社

最初の記事に書いたとおり、最初のALPは GTkをもとにした凡庸な UIで、必要なことはできるけど使っていて楽しいUIとは別のものでした。 ACCESSという、受託開発メインでやってきた会社しても、そこを尖らせた UIを作る気概はあまりありませんでした。

それが変わったのは、イスラエルの Emblaze社とくんだからでしょう。 その名前を聞いたのは 2008年の夏頃、自分がまだ LIMOで悪戦苦闘していた頃のような気がします。 遙か中東から引き合いがあるという話を伝え聞いて、また軸がブレるんじゃないか、そんなに手を出してていいのかと思ったのを思い出します。 元上司が酒の席か何かで、イスラエルの会社と付き合うのは面倒だ、と前職の経験をはなしてたせいかもしれません。

いずれにしても、そのコンセプトビデオをみて、えらいことになったなあ、とか思ったものでした。 ビジュアルエフェクトがバリバリかかりまくって画面がぬるぬる動く、いままで ACCESSがやってきた UIとは別物です。 こりゃ、作れないだろう、担当チームかわいそうだ、とあまり関わっていなかった自分は他人事のようにおもったものです。

が、2008年の秋頃には否応なく関わることになりました。 無茶なのは確かでしたが、一方無茶を実現するのが面白かったのもあります。 少なくとも政治的妥協物をでっちあげるよりはよかったです。

技術

技術的には一期、二期の ALPを換骨奪胎したものになります。

まず、GUIGTkを全て捨て、OpenGLをベースにした Clutter) というツールキットで作り直すことになりました。 そして、慣性スクロールなどのスマートフォンとして当然の UIが実装されることになりました。 また、前掲のデモにあったようなビジュアルエフェクトは、Emblaze側のエンジニアがシェーダをバリバリいじって作ってくれました。 自分の手の中でそのグラフィックスが動いているのを見た時は、やはりやる気が出たものです。

アプリケーションマネージャは、引き続き使われることになりました。 ユーザIDによるアプリケーションごとのセキュリティ境界などは相変わらずありましたが、 アプリをあとから追加できる設計までにはなっていませんでした。 特に、付属のアプリケーション間での連携は頑張っていましたが、 外部と連携するための Intentのような仕組みには至っていませんでした。

個人的には低レベルな部分を見ていたので、サスペンド、レジューム、ブートシーケンスあたりで苦労しました。 本当にCPUが寝ているかどうかを、電流をはかって調べたのも良い思い出です。 思い返してみればそこでちゃんとレイヤーが切れておらず、アプリケーションレベルの動作がサスペンドなどの基本的な動作に 用意に影響してしまうのがダメダメだったともいえるでしょう。

中止

技術的にはいろいろチャレンジングで面白くはあったものの、いろいろな問題があって開発は 2010年の夏には正式に中止されることになります。 「イスラエルのEmblaze社、First ELSEの開発中止を発表」にあるように、 販売に達するまでのクオリティを達成できなかったのが一番の敗因でしょう。

ACCESS社員の立場から見ると、開発が遅れているにも関わらず必要な機能を絞り込めず、様々なギミックの実装やデバッグによる時間を取られすぎた、という感もあります。 とはいえ、そういった偏執狂的な妥協のなさというのはあの時点で iPhoneと戦うためには必要なものだったのかもしれません。 キャリアと握ってなんとか出せればいい、というものではあの時点では勝てないので。 勝たなくてもいいから AndroidiPhoneの間でニッチを確保する、などというのも無理だったのは TIZENや Windows Mobileの現状を見れば明らかでしょう。

いずれにしても、あの時点では撤退しかなかったのはもったいないけど仕方がなかったとは思います。

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を支えたかった技術」として書ければいいな。