見えないUIに向かって
UIというのはすべからく使いやすくなくてはならない。まあ、当然のことである。しかし、我々は使いにくい、というか使えない UIを作ってしまう。
特にスマフォに至ってはユーザビリティは命である。とはいうものの、容易に腐った UIが作れてしまう環境でもある。
PCなどと違って、スマフォは日常環境の中でつかわれ、そこに割かれる意識は少ない。電車の中で立ってバランスを取りながらでも使えなくてはならないし、ポケットから出したらすぐに目的の用途にたどり着かなくてはならない。何をするためには、このボタンを押して、と意識しなければならないようではだめだ。スマフォは意識のぼらず、したいことだけが意識にのぼるようにさせねばならない。
と、偉そうなことを書きましたが、そんなものを自分で作れていると断言する自信はありません。機能をつけ足していくたびに複雑になって使えなくなっている気もします。
そこで、ちょっと考えたのが認知能力に負荷をかけるテスト法です。
単純には、被験者にでたらめな数 6桁ぐらいを覚えてもらいます。そしてそのまま何かの操作をしてもらいます。たぶん、被験者は数を忘れないようにするように意識が集中しているはずです。そんな状況でも目的が達成できる UIこそが無の境地でも使える UIなのではないでしょうか。
試しに自分で数を覚えながら自分の母親の電話番号を探す、とかやってみましたがかなり時間がかかりました。ただ、やりすぎると数が長期記憶の方に入ってしまって楽になってしまうかもしれません。
とか書いてみましたが、きっとこういうのはすでに学術的に評価手法としてありそうな気がします。しってたら誰か教えてください。
13日続けてみて
今日もまた遅れてしまいましたが、俺の Advent Calendar 14日目の記事です。
一応13日続けたということで、25日の半分は過ぎたのでちと振り返ってみます。
傾向
やっぱり時間がない
時間厳しいですね、やはり。仕事もそこそこ忙しいので、ネタ仕込む時間がありません。 何とかネタは絞り出せるけど、それをちゃんと記事にするほど突っ込む時間がないということです。アイディアレベルのネタでよければいろいろあるんです。
雑になる
おかげで文章が雑にもなります。推敲の足りない文章を出しちゃったこともありました。特にここ数日は適当な文章を書いてごまかしています。
夜更かしになる
最初のうちは、午前中に書いてたりしたんですが、だんだんずれてきて、会社から帰って家で書いたりするようになって、それで午前中も寝たりしてまた夜中になって、という悪循環が起こりまくりです。
ネタを仕込む動機にはなる
少なくとも最初のうちは、この advent calendarのためにネタをしこんだりしてました。Sketchを hackしたり。あと、没とまでは言ってませんが、やりかけのものもいくつかあります。
普段照れくさくて書かないことをかける
基本、自分は無精であることに誇りを持ってるので、必要ないことやるのはカッコ悪い、と思っています。そういうわけで blogを書くのはかなりやる気のいることなのです。 でも、一度やると決めてしまえば、やる言い訳にはなります。
対策
とりあえず、今回は言い始めたので 25日間頑張ってみるつもりです。
1週間に一度ぐらいにしてネタをもっと作りこめばいい感じで技術的な地検がたまっていきそうなのですが、でもそうするとネタを仕込む時間そのものも 1/7になりそうです。 書く前にちゃんとネタをし込むモチベーションを上げる方法ってないのかしらん。
あと、新技術を会社の人を巻き込んでやれば仕事時間でネタの仕込みができるという一石二鳥メソッドを試してみるべきですかね。gradle 9patch pluginの時はそういう風にできたので書きやすかったし。
あと、ちゃんと寝よう。ということでこの辺にしてお休みなさいませ。
heroku 0th step
数時間遅れですが 俺の Advent Calendar 13日目の記事っす。
いまさらだけど、herokuの tutorialやってみました。仕事柄、動いている herokuの instanceとかを覗くことはあったけど、0からやったことはなかったので。
2時間ぐらいで、一通りできて面白かった。bundler の bugらしきもの でちょっと悩んで、でも issuesみると回避策とか載ってるのもちょっとクエスト達成感があった。仕事の上で叩くコマンドも、やや納得感高くリターンキーを叩ける気がする。
手習い的に簡単なサービスを作ってみたいけど、仕事も佳境感あってひまを見つけられるか。まあ、できたらラッキーぐらいでやってみむ。
あと Config vars のところの例は .. じゃなくて ... を使ったほうが TIMESって意味からしてよくないですかね。と、俺の持ってる Ruby の知恵を最大限生かして突っ込んでみる。
家族シールドと YAuth
酒のんで眠い中書いてます。
今日は家族サービスっていうか、子どもと地下謎への招待状いってたのでした。最後の謎まで解けてよかった。とはいうのの 裏では Ingress Anomaryの Abaddonが沖縄で行われてるのを見てました。で、その後帰っておでんくって酒かっくらって眠たい、というある意味幸せな状態ではあります。
とはいうものの、俺の Advent Calendarにとっては困った状況で、やっと家族が寝て今かけるようになりましたが、ちゃんとしたものを書ける気力も時間もなくこんなの書いてごまかしている状況です。
ホントは家族がなかったら Abaddon行きたかったなあ、というのはあります。仙台の Persepolisぐらいは一人で行きましたが、沖縄を一人で行くのはだめでした。
そういうわけで、ここは家族持ちとしての時間とエネルギーの分配法というのを考えてみるよい機会の気もしますが、そういう壮大なテーマを考えられるほどシラフではないのでよしておきます。
でも、明日は明日で囲碁初段に無謀にも挑戦するので、あんまり考える暇もない気もします。まあ、来年の課題ですね。と毎年いいつつ過ぎてるような。
図書館が便利になった
昔、といっても学生時代は図書館をはしごして週 10冊ぐらい借りていたものですが、最近はちっともいってません。というか、そもそも専門外の本を読まなくなっていかん感じです。電子本も積読状態のものが多くて、これ以上買うのもはばかられる。amazonの ほしい物リスト には十年来のリストが作ってあるけど、買っても読む確率を考えるとな、と放置中。
というような状態の時に その本、図書館にあります Chrome 拡張にであったのでした。カーリル自体は随分前から登録していたのだけどやっぱり、UIが面倒くさくて使ってなかった。でもこの拡張のおかげで、あっという間に近所の図書館にあるか教えてくれる。貸出中かどうかとかもわかる。自分の住む港区の図書館は予約用のボタンまで付いている。
とはいうものの、予約用にはアカウントが必要で、そこは実際に図書館に行かないとだめなのだった。ということで、やっとこのまえ重い腰をあげて図書館に行きアカウント申請してきた。ホントは近いんだけど、なんかお役所っぽい事務処理が面倒くさくて敬遠してたのはある。
旧態依然とした紙の申請書にいろいろ書いてアカウントできて予約してみると、確かに便利だった。図書館のサイトのUIはダサくて、一々確認の window.confirm がうざいものであったけど、現地行ったりするのに比べれば超便利。思わす調子に乗ってほしい物リストの本をかたっぱしから予約しそうになった。
人気の本は 50番めにならんだりして、ああ、やっぱりそんなもんなんだなあ、と思いつつも、予約できればラッキーぐらいだったので気にはならない。あとは順番が回ったことを知らせるメールを見逃さないようにするだけだ。
そういうわけで手元に以下の2つの本が来たんだけど、問題はちゃんと読めるのかしらん。買った本と違って2週間の期限があるから読める、とかなるといいけど。
ああ、あと最後になるけど、これも例のアドベントカレンダーの一部です。はい。
Englishing fast and slow
俺の Advent Calendar 10日めの記事です。これ、書かなきゃだめなんですかね。
時間がないので英語に関する与太話を書きます。
仕事柄、受験サプリ のビデオとかを見ることがあるのです。それで高校ハイレベル英語とか、どんなものかと思って見てみると、さすがにハイレベルなことやってます。熟語とか自分が知らないのが結構出てきます。「Turn down」が「断る」だって初めて知りました。文系学生では常識なんですかね。
対象になってる文章も、そこそこ読ませる論説文のようです。で、それをいろいろ文法とかを元に解説していくわけです。複数形がでてくると抽象的な話の導入だとか。
たしかに言われてみるとそうです。無冠詞の複数形がでてきたら、具体的な話はしにくい。なんとなくわかります。
とはいうものの、自分が英語を読むときにそんなことを考えているか、というと考えてません。そんなことを考えつつ聞いたり読んでたりしたら追いつかない。無意識に脳みそが抽象度を挙げてついていってるんだと思います。
最近読んでる Thinking fast and slow でいえば、System 1が判断して先回りしてる。それに対して、講義では System 2レベルで解説して、もっともなことを言っている。言ってることは間違っていない。
でも、そうやって解釈していくのは大変だよなあ、と思います。「てにおは」を、一々アルゴリズムを追いながら選んでるような感じです。System 1に比べて System 2はむちゃくちゃ集中力を使います。やっぱり、英語がそこそこできるようになった今でもああいう講義について行ける自信はありません。
もちろん、理想としてはそういう訓練をひたすら繰り返して System 1に叩きこみ、System 2を使わずに読めるようになるのでしょう。そして System2からそういうルールも忘れ去っていくのが悟りのようなものでしょう。
でも、実際そういう境地になるのに、ああいう言語化されたルールをもって教えるのが近道なのか知らん。教えるからには言語化しなきゃいけなくて、そのために余計な遠回りをしている気がしなくもありません。臨界期前のこどもなら教えなくても学びます。たしかに、受験サプリが対象としてるのは、脳は柔らかいとはいえ臨界期を過ぎた高校生です。彼らには、何もわからずに英文を読み聞き鍛えていくより、ああいうルールをひたすら覚えこんで 1年後だかの試験に備える、そしてごく一部はそれを System 1に定着させるけど多くは忘れていってしまう、というのがベストなんでしょうか。
まあ、英語は役に立つので System 2で解釈できるより System 1で処理できるようになったほうが得だと思います。でも古文とかになったら、System 2で乗り切って忘却してもいいよなあ、というのも納得します。
そこらへんの科目に対する思い入れの違いが、違和感を覚えた原因ですかねえ。
与太話なんでまとめる気もないんですが、まとめとしては、もっと楽に英語を習熟する方法ありませんかね。
ああ、invokedynamicがな
みなさん、invokedynamic知ってますよね。そう、あの Java8の lambdaで使われてるやつです。
と、振ってみましたが、知らない人も多いような気もします。まあ、とりあえず、動的言語を実装するために JVM7から導入された bytecodeだったけど、Java8の lamdbdaの実装にも使われて、実は JVM6レベルである Android Programmerは lambda使えなくて歯噛みしてるやつです。
ちなみに「がな」は「あったらいいなあ」という意味だと昔ならいました。
という書き出しで始まりましたが、俺の Advent Calendar 8日めの記事です。そんなのだれが気にしてるんだ。あと30分で書かないといかん。
invokedynamicの父
今日なぜそのことを書くかといえば、invokedynamicの父、Charles Nutter 来日記念セミナ として「JRuby loves invokedynamic」という講演があったからです。
Charlesは JRubyの創始者ではありませんが、JVM上で動的言語を実装するのが非効率なのに業を煮やして invokedynamicという動的言語を効率的に実装する仕組みを提案し、見事 Java7に導入されることになったのでした。そういう人が日本で話してくれるとなればいかねばなりません。
invokedynamicとはなにか?
古の JVMにはいろいろなメソッド呼び出しに応じて 4つの invoke bytecodeがありました。 invokestatic, invokevirtual, invokeinterface, invokespecialです。それぞれの内容は名前から推測してください。でも、どれも Javaに向いたもので、Rubyなどのような動的言語を実装するには向いてませんでした。
そこで提案されたのが invokedynamicです。知ってる人には inline method cacheを実装するためのもの、といえばわかるでしょうか。まあ、実際のところ method cacheだけのものではりません。methodを選ぶ仕組みを Java言語自体でカスタマイズできる、まるでリフレクションのような仕組みです。でもリフレクションほど協力ではないので、従来の JVMのオプティマイズがきき、inline化とかいろいろできるぜ、っていうのが売りです。
どういう仕組なのか?
MethodHandle と CallSite ってのが重要なようです。
各 invokedynamic命令には bootstrapというコードがくっついています。これは最初に一回だけ実行され、CallSite (呼び出し場所) を返します。CallSite は以降、invokedynamicを実行するたびに MethdoHandle を返し、JVMはそれを関数ポインタの用に扱ってジャンプします。
CallSite にはいくつかの子クラスがあり、一番単純な ConstantCallSite だと必ず同じ MethodHandle を返すので、JVMはその事実をもとにいろいろ最適化できるというわけです。
この最適化はヒューリスティックにもとづいています。動的言語では、コードの一つの場所で変数の指すオブジェクトの型は実行時までわかりませんが、実際のところ大抵同じ型がくるので一生懸命 virtual tableみたいなものを見るより速くなる、というわけです。Methodhandle自体もいろいろあって、万が一予想外の型がきた時のためにガードをつけたりもできるようです。
JRubyではどうつかっているか
メソッド呼び出し
これはできた経緯からして当然ですね
正規表現とかの定数
コードに現れた正規表現とかを全部コンパイルしておくのはムダです。本当に使うかわからんからです。
そこで、invokedynamicを使い、最初の bootstrapで正規表現をコンパイルするようにします。で、bootstrapの返す CallSiteはできた正規表現オブジェクトをいつも返すようにすれば、その後は分岐とかなしに高速に実行されます。さらには HotSpotの最適化が走って、最初からオブジェクトがおいてあったかのようなコードになるのでしょう。
インスタンス変数の参照
Rubyとかは、インスタンス変数を動的に付け加えられます。で、ここのところを一々名前で呼び出してたのでは遅くてたまらないので、invokedynamicでほげほげしてるらしいです。時間がないので端折ります。
どの程度速くなるのか
ちょっと見せてもらったベンチマークでは、invokedynamicを使わない場合に比べて 2から3倍ぐらい速くなっているようでした。
そもそも JRubyは invokedynamicなしでも CRubyより速いので、invokedynamicつきだと 5倍ぐらいになるよ、と。
お気に入りの例として、RebBlackTreeを実装したときに CRubyはもとより、CRuby + C で書いた実装よりも速くなったと自慢してました。ちょっとかわいい。
で Androidにいつくるの?
えーと、会場は Oracleのオフィスでした。Oracleで Androidの話をするのは禁じられてるらしいです。
というか、そんなの Google次第だよなあ。きっと、なかではもう invokedynamicのある ARTとか動いてて、でも大人の事情で出せなかったりするんじゃないのかなあ。Oracleェ
でなんとか間に合った。あしたは dageziさんが Sketch+CircleCiというネタで書くらしいです。って3分後だよ。
