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

Snippets

対抗して作ってみた。

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

雑に書く。

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

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

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

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

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

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

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

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

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

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

友人が 「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に俺が翻訳して伝えるのじゃ面倒くさいので、共通言語化していかないといけないのかしらん。ハブになる人をつくらないように。難しそうではある。

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

俺の Advent Calendarのまとめ

やっと 25日になりました。俺の Advent Calendarも終わりです。1日だけさぼったり、遅れたりしたのもあったけど概ね完走しました。完走に概ねもくそもあるかという気もするけど。

振り返ってみると、内容はそんなにない日記だったなあ、という気がします。でも内容は問題なくて、書いた問行為自体が重要だったのです。

問題発見に敏感になった

やはり、日々ネタを絞り出すようになって考え方も変わってきました。ちょっと問題に当たると、「あ、これを改善するとネタになるな」とポジティブに考えられるようになりました。まあ、実際に改善するとなると手間がかかったり、先行研究とかを調べたりしなきゃいけなくて成果にまで結びつくことはあんまりないんですけど。でもいくつかは身になったり、今後やることの指針になったりしてます。

本当は、問題発見した時点で書き流して共有できたりするといいのかもしれませんが、読者もいないこんな blogでだらだら「こまった」とかだけ書いていると鬱になるので屋てません。そういう、問題共有サービス (解答はあんまり期待しない) とか作れればいいんでしょうか。Infinite stackみたいな。

ネタにするための動機づけ

普段できないことを勢いづけてできたと思います。 Railsアプリとか、ここ2年ぐらい習作したいなあと言いつつできなかったし、AWSとかも久々に触ったし。

仕事で使ってる Android+Java+CircleCiとかもいいんだけど、どこまでopenにしていいかわからないので、まったく別のことを試さなきゃいけないのがよかったです。

やりたいことを言語化できた

問題発見と通じますが、じわじわと自分が長年やりたかったけどほうっておいたことがあぶりだされてきた気がします。具体的にいえば DevDesignとかの、DevOps的方法論をいろいろな分野に応用して生産性を上げていく、ということでしょうか。

特に Design関係はわけわからんとして手を出してこなかったんですが、会社に Sketch3を買ってもらったこともあり,ちゃんと scaleする Designとかを考えていきたいと思います。

あと、まったく日記では触れてませんが Rustとかもやりたいと思いつつ手を出せてません。それなりに長期間動くわりにリソースが厳しい Mobile Appでは、あの寿命管理とかいけてそうな気がするんですがねえ。まあ、それを有効活用するにはフレームワークから手作りしなきゃいけなくて、オレオレモバイルOSという 10年ぐらい前に ACCESS社とかが夢見たものになるのかもしれませんが。

その他

書く場所についてもちと工夫しました。Qiitaに書いたほうが読まれてる感は出るけど、ポエムを書くのははばかられます。本当は Githubで書くとか JSfiddleで書くのもありだったんだろうなあ、と思いつつそういう実験的なのはできませんでした。

あと、筆が滑ってちょっと迷惑をかけたこともありましたが、そういう配慮についても学べました。余計な事を書くのはいけないと思いつつも、この blog全体が余計なことなので困ったものです。

日本語については、もっとうまくなくてはいけないなあ、と思います。昔のほうが時間があったせいか読ませる日本語を書いていた気がします。「ですます」調と「だである」調は最後まで混ざってます。「ですます」って実はあんまり好きじゃないんですが「だである」で意見を公に置いておくほど我が強くないとか。そういう感じです。

ああ、あと英語で Entryとかあってよかったか。もっと日本人以外に読んでもらえる場に書かないと自己満足になっちゃうけど。

終わりに

そんなこんなでやってよかったと思います。たぶん、毎日 blogはつけなくはなると思うけど、output指向で問題発見してネタを出していく癖をなくさないように適度に、最低でも週1ぐらいで出していこうと思います。

こんなところまで読んでくださってありがとうございました。一応 Merry Christmas & よいお年を。

JavaScriptと Androidと伽藍とバザール

ちょっと code reviewに手間取ってうなってたら 23時前になってて、慌てて書いてます。クリスマスイブだし、とっておきのネタを書こうかとおもったけど、そんなものないのでやや漠然と。

JavaScriptの速さと Androidの遅さ

JavaScriptのフロントエンドのフレームワークの進化が速いのは、衆目の一致するところです。1年前に流行の技術が、あっというまに枯れるどころか、技術的負債のように言われたりします。しかも、その速度自体に加速度がついて進んでいるような雰囲気があります。大変ですねえ。

正直、自分は JavaScriptなんかでまともなアプリなんか組めるかって思ってた強い型とコンパイルがすきなおじさんでした。とはいうものの Quipperに入って Coffeescriptとか接してみて「お、これは案外行ける」と思って VisulanJS とか習作を作ってみたわけです。Promiseも Monadだときいて、Haskellファンとしてはいけてると飛びついたわけです。

で、いまは Reactがきて Reduxがきてます。なんか、傍目で見てると良さそうな感じです。

また、フレームワーク面だけじゃなくて言語面でも随分進化しました。Coffeescriptが人口に膾炙させた Transpilerはいろいろ普及して ES6とかも楽に導入できるようになりました。Dartとかが、chrome native対応するぜ、っていってたのが夢のようです。

ツール群もかなりイケてるみたいです。まあ、個々らへんは自分は brunch止まりなんですが、browserifyとかいろいろ進化してるみたいです (正直ついていっていない)

Androidも追いつこうとはしています。Reduxも Android用の実装 があったりします。言語も Javaだけじゃなくて Kotlinとか Scalaとかもきました (初戦 JVM言語ですが)。 また、build toolも gradleになったと思ったら、bazelの足音が聞こえてきてます。

とはいうものの、JavaScriptの SPA界の進化には追いついていない感があります。

なぜ Androidは遅れたか

そこで問題なのは、なんで天下の Google様がついていながら Androidの開発環境は遅れたのか、ということです。

それ考えるキーワードの一つが「伽藍とバザール」なのでないでしょうか。

もしかして最近の開発者は伽藍とバザールをご存知ないかも知れません。1999年 (20世紀だ!) に書かれた、Linuxはなぜ普及・発展したかを考察した論文です。「伽藍」というのはプロジェクトのロードマップをちゃんと書いてプロのエンジニアがちゃんと考えて公開するようなプロジェクト、大して「バザール」というのは寄ってたかってみんなで変更を加えて試して見るようなプロジェクトです。

Linusがやったバザール的プロジェクト管理は無謀に思われたが、頻繁なリリースと多大なフィードバックによって結局質のいいプロダクトを作り出すことができた、という今となってはそりゃそうだよなという知見が書かれています。

ということでお察しの通り、Androidは伽藍的な開発なのにたいして、Javasciript (というか WebApp) はバザール的な開発になっていて、その御蔭でその高速な進化を達成できているのでは、というのが今回のあらっぽい推論です。

例:リソースシステム

たとえば最近自分がはまってる Androidのリソースシステムを見てみましょう。

Androidの layout リソースに自分で定義した Viewのクラスを記述することはできます。しかし、自分で定義した Drawableはかけません。色の指定も colors.xmlとかで定義したものだけで、それを少し薄くしたとか書くことはできません。 dimensionも、別の dimensionの 1.5倍とかの指定ができません。SASSとか Jadeとかではいろいろできるのに。

それも、リソースシステムを Googleが握っているからです。開発者が欲しいと思った機能を追加できないのです。最終的には、システム組み込みの inflaterの制限にぶち当たります。

よかれ、と思って Googleが組み込んだ便利な機能が足枷になっているのです。

Googleもかわりつつあるか?

Googleもこの状況には気づいているような気がします。機能をフレームワークに組み込むことなく、一般的なライブラリとして供給しようとしているような気がします。DataBindingとかそうでしょう。そうすれば、新しい機能を使いたい開発者は、エンドユーザが Deviceを更新しなくても組み込むことができます。

さらに重要なのは、サードパーティーライブラリと競争が発生することです。逆にいえば、Appcompatとかは ActionBarSharlockがあってはじめて出てきた気もします。 そこで Googleお仕着せの機能ではなく、より使い良いライブラリがシェアを高めていくようなこともできるでしょう (ある意味、Volleyと okhttpはそんな感じだったかも)。

クリスマスプレゼントに代えて

以上は、非常に大雑把な床屋政談レベルの話です。何しろ、Advent Calendarに穴を開けないように 30分で書き下ろした話なので :)

本当はもっといろんな要素、たとえば WebAppはデプロイが楽だとか、JavaScriptの動作する環境はモバイルと比べてリッチだとかも考えなくてはいけないと思います。そこらへんの考察は正月にお屠蘇でも飲みながらやりたいと思います。

では、あと5分でクリスマスが来ます。Android界も WebApp界もともに発展しますように。ああ、あとついでに iOSも。

わからなかった英単語をとりあえずメモしとくアプリ

予告通り作りました:

enigmatic-mountain-5877.herokuapp.com

むかし、個人的に動かしてたわかんない英単語をとりあえずメモっとくアプリのクローンです。メモっとくだけで、辞書を引いてくれたりするわけじゃありません。ただ、英単語が使われてたページの URLと周りの文章もコピーするので、どういう文脈で使われたのかもわかります。文脈なしに単語だけ覚えても意味ないっすから、という意図があります

ちなみに昔懐かしの bookmarkletを使ってます。使い方としては +a5y0 ってのを bookmarkに Drag'n Dropして、適当な英文のページに行ってわかんない単語を選択して bookmarkletを実行するだけです。

すると A5y0 に登録されたのが見えると。

ほんとは、単語部分をハイライトしたりしたんですが、時間がなくてできませんでした。いまからやります。

あと、みんなの登録した単語がごちゃまぜになっちゃいます。ちゃんとユーザごとの単語帳を作ろうとしたんだけど、そこまでたどり着きませんでした。

まあ、一日 (というか4時間ぐらい)でここまで辿りつけたのはやっぱり Rails楽なんだなあ、というのと、いまさらだけど Backboneやら Chaplinやらは Railsの影響で出来てるんだなあ、と再確認できたのがよかった。そこら辺の知見を Androidにも適用したいけど、それはそれで Rails至上主義みたいになりそうでちと怖い。

ちなみにソースも下記の通り公開しております。突っ込みどころ満載だろうけどご笑覧いただけると幸いです。

github.com

いやでも、こんな感じでコードが走りだすの楽しいですねえ。さすが RnR+Heroku。