Snippets

対抗して作ってみた。

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

メンタルモデルとは

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

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

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

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

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

エラーメッセージ

エラーのときの動作というのは、その典型に見える。ここから卑近な例になって 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。

明日は Railsを書くぞ

ネタが無くなったので、前からチョット考えていたエモいことを下書きしてたら、想像以上にエモくなってしまって、俺のブログでそんなこと言ってもしょうがないなあ、とボツにしてしまった。ということで Advent calendar の埋草を慌てて書いている次第です。

ということで今日は明日の予告編です。題名の通り簡単な Railsアプリを書いてみようと思います。

ずい分前に書いた英単語記録アプリ (Railsなんかつかってない、ベタな CGIって感じのやつ)をさくらで動かしてたんですが、動かなくなってしまった。考えてみるとクレジットカードの有効期限切れてから申請しなおしてない。それじゃしょうがなないな、ということで Railsで再実装してみるかと。実は今年の目標に Railsアプリを作るっていうのもあったし。12/23になってからとりかかるってどれだけものぐさか、って感じですが。

1日だけなので、SPAとかじゃなくて、ベタな Railsアプリになる予定です。でも DBたたいてページャで区切って、ちゃんとやるの初めてなんでできるんだろうか。できればアカウント管理っぽいのまで作りたいけどたどり着くか。わかりません。まあ、できるところまでやります。

Iconの差し替え自動化に挑むも

俺の Advent Calendar 2015 - Adventarの 20日めの記事です。これ書くの久しぶりだな。

Sketch x TravisCI - Qiitaのつづきで、sketch3データがコミットされたら自動的に APKができる DevDesign (DevUI は違うだろうということでこっちにした) むけの環境を作ろうとしてたのでした。

具体的には以下の様なサイクルを作ろうと。DONEとしたところはもうできてます:

  • DONE: Designerが githubに sketch3を push
  • DONE: CircleCIが動いて iconデータを exportして zip
  • それと Jenkinsに知らせる
  • Jenkinsで Android app の repositoryを pullして、教えてもらった zipを取ってきて適宜配置して PRをつくる
  • DONE: CircleCIが PRに反応して APKを作る
  • Designerが APKを downloadして試してみる

今日は、Jenkins用の scriptをしこしこ書いていたのでした。なれない Rubyで。まあ、2年間も Quipperの環境にいれば、門前の小僧レベルで書けるようにはなります。ライブラリを呼び出す glueれべるだし。 ローカルの OS-Xでは動くようになったんですが、残念ながら会社の Jenkinsではなぜか動きません。なんか Gemのキャッシュか何かが悪さをしているようなのですが。門前の小僧の限界です。ほんとうはできたぜって自慢して Qiitaにでも上げたかったんですが。

まあ、できたとしても社内の運用に結構依存してるし、いろんなシステムをまたいだバッドノウハウっぽいものではあるのであんまり公開する意味もないのが虚しいところ。

とりま、明日会社に行って識者にきいてみたいと思います。はい。