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

Snippets

対抗して作ってみた。

俺の 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にでも上げたかったんですが。

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

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

Potatotipsで発表してきた

Potatotips 24 で発表してきました。

内容は Qiitaで書いたものの焼き直しです。

dagezi.github.io

それなりに受けたようなのでよかった。使ってもらえるといいな。

あと、雑談でいろいろ:

  • こういう会合で Androidのエンジニアが少ないのは引きこもりがちだからじゃないか。自分みたいな組み込みおじさんが Androidに流れ込んでるのでキラキラ感が少ないのではないか。
  • iPhone用にアプリがかけなかった頃のことを話すと、そんなころあったんだと若者に驚かれた。
  • 9patchはそもそも否定派も多い。Drawable resourceで頑張りたいと。
  • リクルートは子会社が多くてややこしい。

あと、goodpatch社の UIリソース管理の話とか聞いてみたかったけど聞き忘れた。

おしまい。

見えないUIに向かって

UIというのはすべからく使いやすくなくてはならない。まあ、当然のことである。しかし、我々は使いにくい、というか使えない UIを作ってしまう。

特にスマフォに至ってはユーザビリティは命である。とはいうものの、容易に腐った UIが作れてしまう環境でもある。

PCなどと違って、スマフォは日常環境の中でつかわれ、そこに割かれる意識は少ない。電車の中で立ってバランスを取りながらでも使えなくてはならないし、ポケットから出したらすぐに目的の用途にたどり着かなくてはならない。何をするためには、このボタンを押して、と意識しなければならないようではだめだ。スマフォは意識のぼらず、したいことだけが意識にのぼるようにさせねばならない。

と、偉そうなことを書きましたが、そんなものを自分で作れていると断言する自信はありません。機能をつけ足していくたびに複雑になって使えなくなっている気もします。

そこで、ちょっと考えたのが認知能力に負荷をかけるテスト法です。

単純には、被験者にでたらめな数 6桁ぐらいを覚えてもらいます。そしてそのまま何かの操作をしてもらいます。たぶん、被験者は数を忘れないようにするように意識が集中しているはずです。そんな状況でも目的が達成できる UIこそが無の境地でも使える UIなのではないでしょうか。

試しに自分で数を覚えながら自分の母親の電話番号を探す、とかやってみましたがかなり時間がかかりました。ただ、やりすぎると数が長期記憶の方に入ってしまって楽になってしまうかもしれません。

とか書いてみましたが、きっとこういうのはすでに学術的に評価手法としてありそうな気がします。しってたら誰か教えてください。