EnchantMOON試した雑感
ただ20分触っただけの感想ですので、あまり真に受けないほうが良い気がします。2.3.1適用済です。
まず、書きたくなる程度には話題性があるデバイスなので、書いとこうと思ってしまう、それ自体がなかなか Good Try 感ありますよね。最近のスマホのレビュー、見る気にならんですし。
追記 14:31: 大変有意義なコメントがFacebookに流れてきたので感謝しております。コメントはこの投稿自体より出来ればFacebookやTwitterにお願いします (ブログ本体へのコメントは単に見てないのです！)
● 総じて微妙、という結論はさておき。
まず前評判や社長の発言等から、このデバイスには多分3つの衝突する哲学を抱えている気がします。
割り込み中に間違った処理をするとどうなるか、大昔スケジューラを書き換えていた時、私も痛いほど味わった。
具体的には、スケジューラとあるカーネルレベルのデバイスドライバを通信させるというドライバを書いていた。そしてドライバーがとりあえず実装できたので、installするためにリターンキーを押した。
……ええーと、改行すらされないんですけど。ああああ、何も入力受け付けない受付ないぃぃぃうりぃぃぃ、Ctrl+Alt+Deleteなんてリッチな機能うごかねーよばかーぁぁぁ (電源長押しで切る)
要は、そういうローレベルでコードがバグっていれば、Javaのような高級なExceptionも発生しないし、Cのようにセグフォも発生しない。最悪、Kernel Panicすら発生しない。文字通りマシンが永久に泊まる。だって、発生させるロジックに届かないんだから。
Linuxのような市井の汎用OSで、割り込み中にロジックを追加するようなAPIを追加するのは、実装が複雑になる上にOS全体のスタビリティに対する深刻な脅威になってしまう。マッシュアップ上等という文化がセキュリティの脅威をばんさか世の中に流布した、その100倍くらいの脅威が世の中で起こる。自動車のブレーキが外部から踏まれるなんて日常茶飯になりかねない。変に入れると、FUSEよろしくKernel割り込みハンドラー on User Space という「えーまじかｗｗ」ということをやりだす人が現れるかもしれない。トイレのウォシュレットのbluetoothのパスワードが0000固定になるというレベルはまだお優しいですね。
というのはまぁいいや。
というわけでLinuxでこのたぐいの機能を追加するのは筋が良くない、という意見があれば、それは多分適切だと思う (舵を切るのなら、まぁいいんだけど)
でもさ、EnchantMOONは下位層を見せてないじゃん。
だから、そこまでやってるんだと思ったんです。
だって口上がそういう感じだったし。まるで紙に書いてあるような書き味、みたいな。
でも、書き味についていうと、全然そうなってないんです。アップデート後でもそんなに快適じゃない。せめて60fpsでリアルタイム反応するくらいにはして欲しかったのに、なってないのです。リアルタイムOSの話を出すレベルにすら至ってない感じがばりばり。
なんでか？
多分なんですが、上位層に非常にリッチなレイヤをぶちこむと、どうしても自分でOSレベルですんごい大鉈は振るえなくなるのだ、というのを予想してます。どこかで「巨人の肩」に乗らないとならない世間ですので。
特にブラウザ。これはある意味でOSの上にOS乗っけるようなもんです。ブラウザなし、単なるインタラクティブなお絵かきなら、こんなおもくなる理由もなさそう……
はっ
今風のjsが、欲しいわけですよね。すると、ここを本当に下から上まで、あの会社が作るわけには、さすがにいかんだろうと思うわけです。
そうすると、どうしても既存OSをカリカリチューニングして「どや」っ
てことになる、でしょうね。
今回ハードウェアを発注している、その発注先の評判が微妙という話も聞いてますが、どうにしても Android ベース等であれば既存の部品を使って、外部の工場に既存のLinux系ハードウェアの亜種の制作として外注し、そこで使われた既存モジュールのドライバのパラメータチューニングに拘泥するだろうと思われます。
そうすると、この「さくさく」作戦をマーケメッセージに当てていたのは、かなりまずかった気がするのです。本当にそういうマーケしてたのか、実は知らんのですが。
世の中の流れは、技術進歩でそのあたりの問題が自然解決するの待ちましょう、という感じ。カリカリチューニングは、半年後のCPUの普通チューニングに負けます、みたいな。
この方法は、大手が半年後にずばっと追い抜いてしまうことに対する、一時的優位にしかならない気がするんです
● プログラマーデバイスなのにチュートリアルは「インタラクティブなタブレット」用、とは
フルjsの端末でゲーム含むリッチエクスペリエンス、はあり得ると思うわけです。そして、これは大手を出し抜く独自性になる可能性もあります。
最近のjs環境を(Kernelパラメータから)チューニングすれば、開発者いわく、STGがさくさく動くそうです。これはあまりやられていません。
ケツイの縦穴もさっくさく動くんでしょうねぇ、背景込みで
＃ これも聞いた話で恐縮ですが、上記のケツイの縦穴は、スプライトの使い方が破滅的すぎて普通に2Dレンダリングすると処理落ちてしまうため移植の壁になった、と聞いたことがあります。背景なければ、まぁなんとかなるんだろうけどな……
で、そうすると、本当はそういう独自のリッチさを全力で見せつけるべきだったんじゃないかとも思うわけです、最初に。ちょっと遅くてもいいのさ、いいか、タッチ数回でゲームが出来上がるのだ、みたいな
実際、(残念ながら20分しか触れていないのですが) 背後にはすごく良い機能を持っているように見えます。ヘルプ出すのも容易ではないのですが、出して一瞥すると「お、おう」と思うものがたくさん。
つまり、これ、多分ガイダンスが適切にされていれば、遅かろうが相当色々遊べるデバイスだろうと見えるのです。多分、ちゃんと半日時間をかけ、社員に根掘り葉掘り聞き、ひと通り使えるようになるまでレビュー書くな、という展開にすれば、もっと評判良かったと思うんですよ。
しかし……
13段の「長い」チュートリアルにそれらは一切出てこないのであります。
13段のチュートリアルが長く感じて、半日の講習会が短く感じる、そういうデバイスです。
チュートリアルでは一瞬足りともその機能性は見えてこない。おーい、指で円描くときに処理落ちしてどうしようもないんだけど、というところにしか目が行かない。
このチュートリアル、オーラがAndroidやiPadのそれなんですよね。基本的な操作を見せるためのものです……実用デバイスのチュートリアルに見えますね
EnchantMOONは実用デバイスだったんでしょうか？
最近のお約束で色々説教されるせいで、WiFiで5GHz帯掴まない「実用」デバイスを見ると顔が歪むようになってしまいました。EnchantMOON、5GHzつかむ？
そういう側面が自然と漏れでてくるのは、意識が
このデバイスなら全然良くないと思います。おさわり会すらするべきではないかもしれない。もし、ファーストインプレッションがさくさくデバイス側に偏ってるのなら、なおさら。
使ってて思ったんですが、もし処理落ちを完全に殺せないのなら、「講習会なしでこのデバイス使わせないほうが良い」と思うんですよ。もう、中途半端な理解で語ろうとする私みたいなのには、一切触れさせない。
知っている人が、知っているオーラを出して、したりがおでブロックを組み立てて「どや」って言って、それを10回見せつけられるまで、利用者はデバイス自体は見てはいけない。まず、催眠をかけるのだ。これはタブレットではないのだと。
ヘルプを一覧したときに「おおう、これは、うまく使えたら面白そうだが……例を試す前に飽きるな(´・ω・`)」と思ったのです。
チュートリアルに記載されるショートカットは処理落ちし、JavaScriptの深淵に近づく前に、みなさんレビュー書いてこのデバイスは放置です。すると、どう見てもこのデバイスの良さは喧伝しようがない。たっかい4万のダメタブレット、まる。
対照的なチュートリアルとして、最近のコンソール系ゲームのチュートリアルは参考になるのかも知れません。
俺達は世界を救うのだ。お前はそのために、まず目の前のゴブリンを倒せ。倒し方を、今教える。
最近のゲームのチュートリアルが操作「のみ」に終わっていないというのは、やってみれば分かるのです。というか、説明書読まないでしょう。説明書読む奴、操作ではなくエスプリの効いた何かを探してるでしょう。
違うのは、EnchantMOONのゴールは、買った時点でわかっていないこと。だとすれば、やはり4万円に対して6万円の2日間講習会売ったほうが、よかったんじゃねーかと。
● 本当のねらいはなんだろう。
長くなったので、もう一度最初の「EnchantMOONに見える衝突しあう哲学」を列挙します。
でも、仮にこのデバイスの世界観を拡張するとしても、上の話が「相互に衝突した哲学」だという点は変わらない気がしています。どこかが伸びていくのでない限り、このデバイスは「あれもこれも」の平凡さに引きづられて、愛されることなく忘れ去られそう。
大人の事情はともかくとして、上の3つのどれが重要なのか、というのがやはり知りたいなぁと思うのです。
社長の発言を見るに、どうしても2番目を推したい気がしている。一方、メッセージングには1番目と3番目が混じる。複雑な世界ですので、そういうこともあるでしょうが、最終的には自然と2番目に集約されて「いかなければならない」んじゃないかなぁと思います。
その方向にこのデバイスが進化すると仮定すれば、さくさく感が低いというレビューで終わるのはちょっともったいないんです。このレビューも、その範囲にほとんど留まってますが、本来はしっかりJSで色々実装してみてこそですよね。
さて、触れた時間よりはるかに長い時間書くのに費やしてしまった。充電しときましょ。
……micro USBじゃないじゃんばかー！
--
長めの追記 16:11:
あまりに読まれる量が通常より多くなって戦々恐々としてるので、上記の記事で今のところ危険度が高いところを修正したり弁解したりしときますね。
ドライバ周りの理解があやふやっぽいので気をつけろ、という指摘が複数ありました。特に「割り込み時にまともに処理出来ない」的な部分は「誤り」です。すみません。
私も正しく説明出来ないので、後はT-Kernelとかその辺りに詳しい人が補足記事とか書いてくれると助かります。後で状況が分かったらアップデートします (もうそのときにはここは読まれてないと思うけどな)
Facebookでいくつか良い記事を教えてもらいました。
http://www.coins.tsukuba.ac.jp/~yas/coins/os2-2010/2011-02-15/
で、もうひとつ、「外野」としては上の話よりさらに重要な話ですが、そもそもTizenの 10us あたりの話、今回の「もっさりしている」案件とは実際には関係ないと予想されます。つまり「かんけーねぇ」
上で書いたその部分、単なる与太話であり、「ああ、そういえばそういう話あったな」という程度でダンプした内容です。どのくらいの本気度でどこまで行くかの極北の絡みで思いついた、という程度の意味しかないんですよねぇ。
今消すと不自然なので、ほぼオリジナルのまま残しますが、本当にきちんと意見を書くのなら、ここは推敲時点でバッサリ削除するべきかと思います。幸い色々教えてもらいましたけど、正直困ったねんな。知識足りないところを晒すと、恥ずかしいな。
でま、「関係ない」ことに関する私なりの根拠。60fps は1フレーム 16ms です。10us を1ms粒度で実行せざるを得ない何らかの制約 (割り込みの話でもなく) があるとしても、それだけであそこまで体感で遅くなったりはしないはずです。あれ、1フレームのズレとかそういうレベルじゃないですから。
また、例えば、ゲームレベルのリアルタイム処理が必要なアプリも既存の汎用OSの範囲内でちゃんと動きます。別に東方遅いマシンでもそこそこ動くだろ (注: GPU弱いと最近のは結構うごきません……)
でま、EnchantMOONの範囲でまいくろせっくまで絶対に要らんだろう、という意見はそれ自体おそらく正しいのですし、私もそう思います。ヘネパタ引くまでもない、ボトルネックで全体性能は完全に制約される。
ただ、「紙のように滑らか」があまり実現できてないので、どのレイヤでとちったかを考えた時に「OSはリアルタイムOSであるべきだったのか？」みたいな話がふと頭の中に上がったわけです。そういう「脳内が溢れた」一部がTizenの下りでした。
何故遅いのかはプロファイル取らない限り何も言えないわけですが、気になるのはある人の発言「前のおさわり会とかではもっとサクサク動いてた気がするんだけど」というくだりでしょうか。何があったんでしょ。私は昔の様子を見てないので、その辺りは、仮にそうだったとして、理由はよくわかりません。
OSに何を選定するところから始めるのがこのプロジェクトをやる場合には適切なのか、どうすれば本当にあのデバイスが使いやすくなるのか、なんて話を本気でするのなら、これはもう実際に作っている陣営にいなかったらわからないでしょう。
ブログ書いてるとそういうところにリーチできないでものを書くのが怖くなります。とはいえ今回久しぶりに全力で書いたのは、おそらくはEnchantMOONから引き出せるものがそれであるだろうと思ったからです。で、何故か自分のブログへのコメントで自分が勉強するというWAKE WAKA LAKAな展開になっております。
世の中難しいな！
● 追記 (2013-08-07 9:29)
「『さっくさく描けるお絵かきデバイス』といった方向性でマーケされたことはないんじゃない？」という指摘をいただきました。
http://enchantmoon.com/feature/
確かに「お絵かき」を前面には出してないですね。
というかデバイス実際に触れれば分かりますが、それほどガッチガチの絵は描けません。パレットや色、という話もありません。どちらかというと、鉛筆によるスケッチ、が正しい気がします (以下で書きますが「手書き」デバイスというのが適切で「手描き」デバイスは過剰な期待がします)。以下、追記の項にて訂正していきます (読まれすぎてるので原文訂正しません)
じゃ、どういう経緯でそういう「哲学」を私が読み取ったか、という話を修正がてら考察してみます。
まぁ、基本的には公式のいくつかの説明と、社長等の発言から妄想したんですよね。
公式ページから
「追従性」の定義が「さくさく」と対応するとして考えれば、まぁ上のような表現系から「入力にきっちり反応してくれる」という範囲で「さくさく」という期待になる、と思われます。ちなみに私は「追従性」という表現では話は書いてないんですけれども。
「滑らかな書き味」を達成するためにある程度のリアルタイムの「追従性」は必要で、その「ある程度」を達成できていない、と皆が感じている、という意味では、「追従性がいい」は上の公式の表現において「言っている」と言っていいんじゃないかと思います。
という風に固く書きますが、「言ってないけど、言ってる気がしない？」という雰囲気でもここはいい気がするのね。「紙の再発明」ってどばーんとぶちあげてるときに、書き味が「あそこまで」遅延すると、やはりみんな「(´・ω・`)」って顔になるでしょう。
ここでまぁ良くなかったのは、私が例に出したのがリアルタイム性能の話だというところでしょうかねぇ。前回の追記に書いてますが、実際には多分、そういうガチリアルタイム性能の話では無いです。他の方から指摘いただきましたが「後からバックグラウンド処理追加しすぎてどんどん遅くなったんじゃない」とか「エフェクト綺麗にしたらガンガン遅くなったんじゃない」とか、そういうレベルの話なのかもしれず。どうでも良いですが無駄にTizen絡めたら組み込み系の人から面白いコメントをもらったので私だけものすごく得してます。さーせん
さてま、「絵描き」の部分や。
ローカルのインプットでどこかで絵描きに使わせたかった、という話を聞いた気がしますが、まぁこれは公式な発言とは言いがたい。
＃ ただ、手描き風の絵はチュートリアル等、UIの随所に出てきてるので、あながち完全に外れている気もしないでもないんですけど。
残念ながらこのブログで一言一句厳選してるわけではありません。というわけで「さっくさく描けるお絵かきデバイス」という表現が正確にプロデューサの脳の中を反映しているようではない、という指摘は間違いのないところですね。指摘ありがとうございます。
多分、もっと主要なメッセージングは、どちらかと言えば手「書」きであり、文字認識という指摘が(仮に)あれば、それのほうが実際の製作者側の意図に近いはずです。
指摘受けてなるほどなぁと思うに、全体的に「個人の妄想がオリジナルのメッセージからあらぬ方向に発散しすぎてるんだなぁ」という気がします。ブログということもあり、今回かなり「生」の印象を書きました (この追記も含めて)。そういうときに、結構基本的なレベルで、私はEnchantMOONが実際にどう公式に宣伝されてるか全く知らんことに気付かされるわけです。大体上の機能のページ、今始めてみたわ。これがジャーナリストなら0点付けられて然るべきです。れーてん
でも、ここを読みに来る人、半分以上そういう人だったりしないかしら。消費者です。消費者は報道やそれ以外のメッセージをものすごく強烈に受け取ります。中の人がしたり顔で「このデバイスは〜〜だ」と言い出したら、真に受けて全力でそれに挑みます (消費者として)。現代のものづくりは本当に大変だと思うわけです。
まず、書きたくなる程度には話題性があるデバイスなので、書いとこうと思ってしまう、それ自体がなかなか Good Try 感ありますよね。最近のスマホのレビュー、見る気にならんですし。
追記 14:31: 大変有意義なコメントがFacebookに流れてきたので感謝しております。コメントはこの投稿自体より出来ればFacebookやTwitterにお願いします (ブログ本体へのコメントは単に見てないのです！)
● 総じて微妙、という結論はさておき。
まず前評判や社長の発言等から、このデバイスには多分3つの衝突する哲学を抱えている気がします。
- さっくさく描けるお絵かきデバイス
- 全人類プログラマー計画の布石
- ギークや子供がすぐ試せるたぐいのYET ANOTHER タブレット
結論から言えば2番目以外は切るべきだと思いました。
● Linux を使っている限りは大手以上のレスポンス性能は出せなそう
前評判で、Linux Kernelレベルまでチューニングを施したと聞きました。しかしユーザ視点で言えば、基本的なレスポンスがiPadどころか最新のAndroidデバイスに劣っています。
脱線しますけど、ある知り合いがすごくギークチックで私が好きな話題をくれました。Tizenのリアルタイム機能のことです。(昔Kernel周りを研究していた)私が理解した範囲で言うと、こう。
Linux Kernel では、タイマー割り込み間隔の間に飛んできた外部からの入力は一旦プールされる。通常の範囲だと、1msが最速の割り込み間隔になる。ソースレベルで書き換えればもう少し小さく出来るはずだが、今度は割り込み線から実際にKernel内の所定の関数を読んでスケジューラを再度回すコストが跳ね上がるので、通常の範囲だと1ms〜10msだった気がする (これも5年以上前の知識ねんなｗｗ)。
問題は、本当のリアルタイム処理というのは(みりせっくのmsではなく、まいくろせっくの)usの単位で即座にレスポンスをして欲しいというところだ。昨今の高速な回線であれば1usはなくとも10us〜100usはあり得る。この要求が来た瞬間に10usかけて応答すれば、遅延は10usで済む。
これをもし、Linux Kernel の通常のデバイスドライバで書くと、ちっとやそっとでは1msの壁も超えられない。あえて酷い表現をすると100倍遅いデバイスの出来上がりである。
Tizenにはそういう外部割り込みに対する処理をドライバレベルで記述できてしまう機能セットがある、らしい。そのため、理想的にはLinux Kernelよりもリアルタイム性能の高い実装が可能なんだそうだ。全く知らないんだが、tron系もそういうAPIがあるんかもしらん (あっちが先だ)
Linux Kernel 上でそれをやるにはメインストリームに入っていない独自のパッチを当てる必要があるという。かつてリアルタイム系開発者 (ARM系？) がそういう話をLinuxコミュニティに持ち込んだ(という)が、受け入れられなかったそうだ。
しかし、Linux (というかもしかするとUNIX一般) のベースとなる哲学として、この「割り込み中に危険な処理を許す」機能性は受け入れがたいので、上記のような(発狂)パッチは永久にメインストリームに入ることがない、という結論だったそうだ (この辺りが間違っているとすれば、多分教えてくれた人の説明間違いではなく私の理解間違い。誰か指摘してください)
しかし、Linux (というかもしかするとUNIX一般) のベースとなる哲学として、この「割り込み中に危険な処理を許す」機能性は受け入れがたいので、上記のような(発狂)パッチは永久にメインストリームに入ることがない、という結論だったそうだ (この辺りが間違っているとすれば、多分教えてくれた人の説明間違いではなく私の理解間違い。誰か指摘してください)
そりゃそうだよと思う。
割り込み中に間違った処理をするとどうなるか、大昔スケジューラを書き換えていた時、私も痛いほど味わった。
具体的には、スケジューラとあるカーネルレベルのデバイスドライバを通信させるというドライバを書いていた。そしてドライバーがとりあえず実装できたので、installするためにリターンキーを押した。
……ええーと、改行すらされないんですけど。ああああ、何も入力受け付けない受付ないぃぃぃうりぃぃぃ、Ctrl+Alt+Deleteなんてリッチな機能うごかねーよばかーぁぁぁ (電源長押しで切る)
要は、そういうローレベルでコードがバグっていれば、Javaのような高級なExceptionも発生しないし、Cのようにセグフォも発生しない。最悪、Kernel Panicすら発生しない。文字通りマシンが永久に泊まる。だって、発生させるロジックに届かないんだから。
Linuxのような市井の汎用OSで、割り込み中にロジックを追加するようなAPIを追加するのは、実装が複雑になる上にOS全体のスタビリティに対する深刻な脅威になってしまう。マッシュアップ上等という文化がセキュリティの脅威をばんさか世の中に流布した、その100倍くらいの脅威が世の中で起こる。自動車のブレーキが外部から踏まれるなんて日常茶飯になりかねない。変に入れると、FUSEよろしくKernel割り込みハンドラー on User Space という「えーまじかｗｗ」ということをやりだす人が現れるかもしれない。トイレのウォシュレットのbluetoothのパスワードが0000固定になるというレベルはまだお優しいですね。
というのはまぁいいや。
というわけでLinuxでこのたぐいの機能を追加するのは筋が良くない、という意見があれば、それは多分適切だと思う (舵を切るのなら、まぁいいんだけど)
でもさ、EnchantMOONは下位層を見せてないじゃん。
だから、そこまでやってるんだと思ったんです。
だって口上がそういう感じだったし。まるで紙に書いてあるような書き味、みたいな。
でも、書き味についていうと、全然そうなってないんです。アップデート後でもそんなに快適じゃない。せめて60fpsでリアルタイム反応するくらいにはして欲しかったのに、なってないのです。リアルタイムOSの話を出すレベルにすら至ってない感じがばりばり。
なんでか？
多分なんですが、上位層に非常にリッチなレイヤをぶちこむと、どうしても自分でOSレベルですんごい大鉈は振るえなくなるのだ、というのを予想してます。どこかで「巨人の肩」に乗らないとならない世間ですので。
特にブラウザ。これはある意味でOSの上にOS乗っけるようなもんです。ブラウザなし、単なるインタラクティブなお絵かきなら、こんなおもくなる理由もなさそう……
はっ
- 全人類プログラマー計画の布石
今風のjsが、欲しいわけですよね。すると、ここを本当に下から上まで、あの会社が作るわけには、さすがにいかんだろうと思うわけです。
そうすると、どうしても既存OSをカリカリチューニングして「どや」っ
てことになる、でしょうね。
今回ハードウェアを発注している、その発注先の評判が微妙という話も聞いてますが、どうにしても Android ベース等であれば既存の部品を使って、外部の工場に既存のLinux系ハードウェアの亜種の制作として外注し、そこで使われた既存モジュールのドライバのパラメータチューニングに拘泥するだろうと思われます。
そうすると、この「さくさく」作戦をマーケメッセージに当てていたのは、かなりまずかった気がするのです。本当にそういうマーケしてたのか、実は知らんのですが。
世の中の流れは、技術進歩でそのあたりの問題が自然解決するの待ちましょう、という感じ。カリカリチューニングは、半年後のCPUの普通チューニングに負けます、みたいな。
この方法は、大手が半年後にずばっと追い抜いてしまうことに対する、一時的優位にしかならない気がするんです
● プログラマーデバイスなのにチュートリアルは「インタラクティブなタブレット」用、とは
フルjsの端末でゲーム含むリッチエクスペリエンス、はあり得ると思うわけです。そして、これは大手を出し抜く独自性になる可能性もあります。
最近のjs環境を(Kernelパラメータから)チューニングすれば、開発者いわく、STGがさくさく動くそうです。これはあまりやられていません。
ケツイの縦穴もさっくさく動くんでしょうねぇ、背景込みで
＃ これも聞いた話で恐縮ですが、上記のケツイの縦穴は、スプライトの使い方が破滅的すぎて普通に2Dレンダリングすると処理落ちてしまうため移植の壁になった、と聞いたことがあります。背景なければ、まぁなんとかなるんだろうけどな……
で、そうすると、本当はそういう独自のリッチさを全力で見せつけるべきだったんじゃないかとも思うわけです、最初に。ちょっと遅くてもいいのさ、いいか、タッチ数回でゲームが出来上がるのだ、みたいな
実際、(残念ながら20分しか触れていないのですが) 背後にはすごく良い機能を持っているように見えます。ヘルプ出すのも容易ではないのですが、出して一瞥すると「お、おう」と思うものがたくさん。
つまり、これ、多分ガイダンスが適切にされていれば、遅かろうが相当色々遊べるデバイスだろうと見えるのです。多分、ちゃんと半日時間をかけ、社員に根掘り葉掘り聞き、ひと通り使えるようになるまでレビュー書くな、という展開にすれば、もっと評判良かったと思うんですよ。
しかし……
13段の「長い」チュートリアルにそれらは一切出てこないのであります。
13段のチュートリアルが長く感じて、半日の講習会が短く感じる、そういうデバイスです。
チュートリアルでは一瞬足りともその機能性は見えてこない。おーい、指で円描くときに処理落ちしてどうしようもないんだけど、というところにしか目が行かない。
このチュートリアル、オーラがAndroidやiPadのそれなんですよね。基本的な操作を見せるためのものです……実用デバイスのチュートリアルに見えますね
EnchantMOONは実用デバイスだったんでしょうか？
最近のお約束で色々説教されるせいで、WiFiで5GHz帯掴まない「実用」デバイスを見ると顔が歪むようになってしまいました。EnchantMOON、5GHzつかむ？
そういう側面が自然と漏れでてくるのは、意識が
- ギーク御用質のすぐ試せるたぐいのタブレット
このデバイスなら全然良くないと思います。おさわり会すらするべきではないかもしれない。もし、ファーストインプレッションがさくさくデバイス側に偏ってるのなら、なおさら。
使ってて思ったんですが、もし処理落ちを完全に殺せないのなら、「講習会なしでこのデバイス使わせないほうが良い」と思うんですよ。もう、中途半端な理解で語ろうとする私みたいなのには、一切触れさせない。
知っている人が、知っているオーラを出して、したりがおでブロックを組み立てて「どや」って言って、それを10回見せつけられるまで、利用者はデバイス自体は見てはいけない。まず、催眠をかけるのだ。これはタブレットではないのだと。
ヘルプを一覧したときに「おおう、これは、うまく使えたら面白そうだが……例を試す前に飽きるな(´・ω・`)」と思ったのです。
チュートリアルに記載されるショートカットは処理落ちし、JavaScriptの深淵に近づく前に、みなさんレビュー書いてこのデバイスは放置です。すると、どう見てもこのデバイスの良さは喧伝しようがない。たっかい4万のダメタブレット、まる。
対照的なチュートリアルとして、最近のコンソール系ゲームのチュートリアルは参考になるのかも知れません。
俺達は世界を救うのだ。お前はそのために、まず目の前のゴブリンを倒せ。倒し方を、今教える。
最近のゲームのチュートリアルが操作「のみ」に終わっていないというのは、やってみれば分かるのです。というか、説明書読まないでしょう。説明書読む奴、操作ではなくエスプリの効いた何かを探してるでしょう。
違うのは、EnchantMOONのゴールは、買った時点でわかっていないこと。だとすれば、やはり4万円に対して6万円の2日間講習会売ったほうが、よかったんじゃねーかと。
● 本当のねらいはなんだろう。
長くなったので、もう一度最初の「EnchantMOONに見える衝突しあう哲学」を列挙します。
- さっくさく描けるお絵かきデバイス
- 全人類プログラマー計画の布石
- ギークや子供がすぐ試せるたぐいのYET ANOTHER タブレット
でも、仮にこのデバイスの世界観を拡張するとしても、上の話が「相互に衝突した哲学」だという点は変わらない気がしています。どこかが伸びていくのでない限り、このデバイスは「あれもこれも」の平凡さに引きづられて、愛されることなく忘れ去られそう。
大人の事情はともかくとして、上の3つのどれが重要なのか、というのがやはり知りたいなぁと思うのです。
社長の発言を見るに、どうしても2番目を推したい気がしている。一方、メッセージングには1番目と3番目が混じる。複雑な世界ですので、そういうこともあるでしょうが、最終的には自然と2番目に集約されて「いかなければならない」んじゃないかなぁと思います。
その方向にこのデバイスが進化すると仮定すれば、さくさく感が低いというレビューで終わるのはちょっともったいないんです。このレビューも、その範囲にほとんど留まってますが、本来はしっかりJSで色々実装してみてこそですよね。
さて、触れた時間よりはるかに長い時間書くのに費やしてしまった。充電しときましょ。
……micro USBじゃないじゃんばかー！
--
長めの追記 16:11:
あまりに読まれる量が通常より多くなって戦々恐々としてるので、上記の記事で今のところ危険度が高いところを修正したり弁解したりしときますね。
ドライバ周りの理解があやふやっぽいので気をつけろ、という指摘が複数ありました。特に「割り込み時にまともに処理出来ない」的な部分は「誤り」です。すみません。
私も正しく説明出来ないので、後はT-Kernelとかその辺りに詳しい人が補足記事とか書いてくれると助かります。後で状況が分かったらアップデートします (もうそのときにはここは読まれてないと思うけどな)
Facebookでいくつか良い記事を教えてもらいました。
http://www.coins.tsukuba.ac.jp/~yas/coins/os2-2010/2011-02-15/
で、もうひとつ、「外野」としては上の話よりさらに重要な話ですが、そもそもTizenの 10us あたりの話、今回の「もっさりしている」案件とは実際には関係ないと予想されます。つまり「かんけーねぇ」
上で書いたその部分、単なる与太話であり、「ああ、そういえばそういう話あったな」という程度でダンプした内容です。どのくらいの本気度でどこまで行くかの極北の絡みで思いついた、という程度の意味しかないんですよねぇ。
今消すと不自然なので、ほぼオリジナルのまま残しますが、本当にきちんと意見を書くのなら、ここは推敲時点でバッサリ削除するべきかと思います。幸い色々教えてもらいましたけど、正直困ったねんな。知識足りないところを晒すと、恥ずかしいな。
でま、「関係ない」ことに関する私なりの根拠。60fps は1フレーム 16ms です。10us を1ms粒度で実行せざるを得ない何らかの制約 (割り込みの話でもなく) があるとしても、それだけであそこまで体感で遅くなったりはしないはずです。あれ、1フレームのズレとかそういうレベルじゃないですから。
また、例えば、ゲームレベルのリアルタイム処理が必要なアプリも既存の汎用OSの範囲内でちゃんと動きます。別に東方遅いマシンでもそこそこ動くだろ (注: GPU弱いと最近のは結構うごきません……)
でま、EnchantMOONの範囲でまいくろせっくまで絶対に要らんだろう、という意見はそれ自体おそらく正しいのですし、私もそう思います。ヘネパタ引くまでもない、ボトルネックで全体性能は完全に制約される。
ただ、「紙のように滑らか」があまり実現できてないので、どのレイヤでとちったかを考えた時に「OSはリアルタイムOSであるべきだったのか？」みたいな話がふと頭の中に上がったわけです。そういう「脳内が溢れた」一部がTizenの下りでした。
何故遅いのかはプロファイル取らない限り何も言えないわけですが、気になるのはある人の発言「前のおさわり会とかではもっとサクサク動いてた気がするんだけど」というくだりでしょうか。何があったんでしょ。私は昔の様子を見てないので、その辺りは、仮にそうだったとして、理由はよくわかりません。
OSに何を選定するところから始めるのがこのプロジェクトをやる場合には適切なのか、どうすれば本当にあのデバイスが使いやすくなるのか、なんて話を本気でするのなら、これはもう実際に作っている陣営にいなかったらわからないでしょう。
ブログ書いてるとそういうところにリーチできないでものを書くのが怖くなります。とはいえ今回久しぶりに全力で書いたのは、おそらくはEnchantMOONから引き出せるものがそれであるだろうと思ったからです。で、何故か自分のブログへのコメントで自分が勉強するというWAKE WAKA LAKAな展開になっております。
世の中難しいな！
● 追記 (2013-08-07 9:29)
「『さっくさく描けるお絵かきデバイス』といった方向性でマーケされたことはないんじゃない？」という指摘をいただきました。
「追従性がいい」とか「さっくさく描けるお絵かきデバイス」なんてそもそも言ってないという記憶なんだけどどっかでそういうこと言ってましたっけ
http://enchantmoon.com/feature/
確かに「お絵かき」を前面には出してないですね。
というかデバイス実際に触れれば分かりますが、それほどガッチガチの絵は描けません。パレットや色、という話もありません。どちらかというと、鉛筆によるスケッチ、が正しい気がします (以下で書きますが「手書き」デバイスというのが適切で「手描き」デバイスは過剰な期待がします)。以下、追記の項にて訂正していきます (読まれすぎてるので原文訂正しません)
じゃ、どういう経緯でそういう「哲学」を私が読み取ったか、という話を修正がてら考察してみます。
まぁ、基本的には公式のいくつかの説明と、社長等の発言から妄想したんですよね。
公式ページから
- OSレベルの最適化により滑らかな書き味を追求
- スムースな文字認識エンジン
- （Androidアプリ実行の互換性を持たせず）専用機にすることで、レスポンスを確保できます。
「追従性」の定義が「さくさく」と対応するとして考えれば、まぁ上のような表現系から「入力にきっちり反応してくれる」という範囲で「さくさく」という期待になる、と思われます。ちなみに私は「追従性」という表現では話は書いてないんですけれども。
「滑らかな書き味」を達成するためにある程度のリアルタイムの「追従性」は必要で、その「ある程度」を達成できていない、と皆が感じている、という意味では、「追従性がいい」は上の公式の表現において「言っている」と言っていいんじゃないかと思います。
という風に固く書きますが、「言ってないけど、言ってる気がしない？」という雰囲気でもここはいい気がするのね。「紙の再発明」ってどばーんとぶちあげてるときに、書き味が「あそこまで」遅延すると、やはりみんな「(´・ω・`)」って顔になるでしょう。
ここでまぁ良くなかったのは、私が例に出したのがリアルタイム性能の話だというところでしょうかねぇ。前回の追記に書いてますが、実際には多分、そういうガチリアルタイム性能の話では無いです。他の方から指摘いただきましたが「後からバックグラウンド処理追加しすぎてどんどん遅くなったんじゃない」とか「エフェクト綺麗にしたらガンガン遅くなったんじゃない」とか、そういうレベルの話なのかもしれず。どうでも良いですが無駄にTizen絡めたら組み込み系の人から面白いコメントをもらったので私だけものすごく得してます。さーせん
さてま、「絵描き」の部分や。
ローカルのインプットでどこかで絵描きに使わせたかった、という話を聞いた気がしますが、まぁこれは公式な発言とは言いがたい。
＃ ただ、手描き風の絵はチュートリアル等、UIの随所に出てきてるので、あながち完全に外れている気もしないでもないんですけど。
残念ながらこのブログで一言一句厳選してるわけではありません。というわけで「さっくさく描けるお絵かきデバイス」という表現が正確にプロデューサの脳の中を反映しているようではない、という指摘は間違いのないところですね。指摘ありがとうございます。
多分、もっと主要なメッセージングは、どちらかと言えば手「書」きであり、文字認識という指摘が(仮に)あれば、それのほうが実際の製作者側の意図に近いはずです。
指摘受けてなるほどなぁと思うに、全体的に「個人の妄想がオリジナルのメッセージからあらぬ方向に発散しすぎてるんだなぁ」という気がします。ブログということもあり、今回かなり「生」の印象を書きました (この追記も含めて)。そういうときに、結構基本的なレベルで、私はEnchantMOONが実際にどう公式に宣伝されてるか全く知らんことに気付かされるわけです。大体上の機能のページ、今始めてみたわ。これがジャーナリストなら0点付けられて然るべきです。れーてん
でも、ここを読みに来る人、半分以上そういう人だったりしないかしら。消費者です。消費者は報道やそれ以外のメッセージをものすごく強烈に受け取ります。中の人がしたり顔で「このデバイスは〜〜だ」と言い出したら、真に受けて全力でそれに挑みます (消費者として)。現代のものづくりは本当に大変だと思うわけです。
