Kotlin in Action を読んだ。けっこうよかった。
Kotlin はさして難しい言語ではなくオンラインの資料もあるので、本を読まずに適当にサンプルとかを真似ながらでも割と使える。なのでひやかし目的なら本はいらないと思う。Scala をやったことがあれば特に。
自分は育児の気晴らしで小さいアプリを Kotlin を使って書いている。そういう風に実際に使うとなるともう少し深く理解して損はなかろうと読んだ。その期待には答えてくれた。この本は丁寧に書かれているし、Kotlin の中の人が書いており authoritative という意味でも安心。1.1 の内容も少しだけ触れている。ただ async/await はでてこない.
Kotlin それ自体について。
モダン言語を一通りひやかした人にとって新しく学べる概念などはまったくない。だいたい Scala の無難でオーバーヘッドの少ないところだけ持ってきたようなデザインだから、サーバ側でわざわざ Kotlin を使うメリットは感じない。一方で Android プログラミングにおける Java の残念さをだいぶ打ち消してくれるので Android プログラマ的にはキラー言語だと思う。Kotlin の開発陣も Android での用途を重く見ているのは各所から感じる。
一通りチュートリアルを冷やかしただけだと気づかない面白い機能、いちばんは inline まわり。
まず inline function に渡した lambda の中で return すると、lambda ではなく外側の inline function から return できる。まじで？おかげで inline function を制御構造に使う柔軟さが増す。Python にあった StopIteration を throw するダサさがない。でもちょっと狂ってるよな。
Inline function の reified type. Java の generics は type erasure で実行時には型が消えてしまうのだけれど、inline function では型の中身に依存できる。たとえば generic class を new できる。まじで？たしかに便利で、ライブラリたちも reified type に大きく依存している。
Outer return にしろ reified type にしろ、Kotlin の inline function は C++ のような単なる高速化のヒントではなく異なる機能を持っている。ちょっとぎょっとするけれど、便利でもある。
そのほか面白かったのは Java クラス相手の nullable の扱い。Nullable の概念がない Java からきた API は引数も戻り値も全て nullable にするのが理論的には正しい。ただ実用的にはかったるすぎるので、それらは platform types という特別な型になる。Platform types は Kotlin 側では Nullable としても Non-nullable としても宣言できる。 けっこう大胆な判断だけれど、まあ悪くない感じ。
個人的には nullable type はあってもなくてもいいと思っているけれど、Null handling まわりの頑張りで便利になってるのも事実だから嫌いではない。CoffeeScript 由来の safe call とか、ふつうにいい。
あとは細かいけど lambda に receiver を渡せるのも気の利いた syntax sugar だと思う。
全体的に無茶せずバランス重視でストレスのない言語だよ Kotlin. Java 混ぜるのも簡単だし、もう余暇アプリはぜんぶこれでいいわ。新しく学ぶ概念がないのは少し退屈だけれど、それは他でやります。
今聞いている White Trash: The 400-Year Untold History of Class in America に出てきた７代目米国大統領かつ Democrats の創業者。すごい荒くれ者のアウトサイダーで、こりゃまるで T 大統領みたいだな・・・と多いながら読んでいたら本人もそれを気取っているらしいと知る。
ちなみに上の記事同様、件の本ではそんなに良い扱いはされていない。
あわせてよみたい:
ところで Working-class 研究として読んでるこの White Trash は歴史の本。iKnow でやって他では見かけないような単語がバンバンでてきて思わぬ満足度が高い。ただアメリカの歴史を知らなすぎるため以前おくさんが買った小中学生向けの歴史の試験対策本でチート。
アメリカ、さすが民主主義の歴史がながいだけあって過去の事例が色々あるのは面白い。そして歴史がある割にあんまし洗練されてきてないところが人類だなと思う。
買った。普通のブラウザ端末、および PDF論文や ebook の読書端末として使おうと思っている。ペンは今のところ使う予定なし。
ブラウザ
すごくちゃんと動く。Chrome OS は Chrome が一番正しく動くプラットホームなので当たり前なのだけれど、普段 Ubuntu というマイナー環境で Chrome を使ってるので差を実感する。比べると Chromebook は全然バグっぽい動きをしないからね。Chrome OS も Ubuntu も Linux じゃん、というかもしれないけれど色々違うのだよ。
欠点。遅い。我慢できない遅さではないけど、速いPCでの動作と比べてキビキビっとはしてない。
普段つかってる XPS13, Macbook Pro, Chromebook Pixel らはみな Intel の速い CPU を使ってるのに対し Chromebook plus は謎の ARM. CPU/GPU 自体の遅さもあるだろうし、 ARM 向けの Chrome OS はまだ Intel 向けほど頑張ってないのかも。
PDF
PDF や ebook はフリップしたタブレットモードで使いたい。現状の出来はいまいち。我慢できるけど慣れと工夫が必要。
まず最初は Chrome 組み込みの PDF ビューアを使おうとした。が、遅すぎてだめ。適当な Android アプリとして Xodo Docs や Google Drive を使ってみる。こいつらは速い。
ただキーボードをフリップした tablet モードと Android アプリ、かつ画面を縦(portrait)にして使うという組み合わせが色々辛い。欠点をあげるとキリがないが、たとえば縦画面にしたときたびたびアプリのウィンドウサイズがおかしくなる。これはたぶんバグ。アプリ切り替えでアプリの動作が不安定になる。これはバグ。フリップした状態でアプリを immersive mode (fullscreen) にする方法がない。これはデザインの欠陥。画面回転のロック設定を、キーボードモードに戻した途端忘れてしまう。たぶんバグ。フリップ状態で Android のように電源ボタンを押してもサスペンドしない。Chromebook は laptop を閉じることでサスペンドする前提だから。
これらはみな根本的な欠陥というよりやる気不足だと思うので, 開発陣が Android タブレット代替品としての Chromebook に本気になれば直ると思う。本気になってほしいなあ・・・。Chromebook は Android と違って新しいソフトウェアのバージョンが継続的に降ってくるから、一年後には半分くらいの問題は直ると期待しつつ我慢して使おう。
E-Book (Play Books)
贔屓目承知でいうと、割といい。これは別にアプリの出来が特別良いという話ではなく、PDF を読む上で最大のフラストレーション要因である portrait な画面の振る舞いから影響を受けないから。EPUB は画面を landscape にしたまま読める。しかも landscape だと 2 ページ同時になる。これがすごくいい。ただし画面の向き以外の問題点は共通。
そういえば Android アプリなのになぜかキーボードでページが送れる。なので laptop モードでも結構使える。ここはよくできてるなと思いました。
画面
12-inch で 2400x1600 の画面。これは良い。ブラウザで使うときもいいし、何かを読むときはすごい良い。この画面サイズと解像度があるから様々な欠点を我慢してでも使おうという気になる。
Flip と Friction
自分にとって初の画面をフリップできる端末。タブレットになる！と思ってたけどそういうものではなかった。iPad にしろ Android にしろ、タブレットなら読み物をするとき 1. 手にとって 2. PIN/指紋 でログインして 3. アプリのアイコンをタップして, 4. ここで読める. 一方 Flip だと 1. 手にとって 2. 画面を開き, 3. キーボードからパスワードをタイプしてログインし, 4. 画面をフリップし, 5. 画面回転をロックし, 6. アプリを起動, 7. ここでようやく読める. 読むまでの friction が多すぎ。
モバイルデバイスたちは friction 削減に血道を上げているのに対し, laptop は腰を据えて使う前提だから friction には甘えがあると思う。スキマ時間にちょっと本を読むみたいな用途に使いにくいのは不満。
どうやって既存の端末たちと住み分けていくかなあ。ブラウザがきちんと動き、かつキーボードがついており、かつコードはかけない。ブラウザを使うぶんには XPS+Ubuntu の細かいイライラがないぶん良い。あと高解像度大画面で活字を読む気分は良い。ということを考えると Chromebook Plus は blog を書いたり電子書籍や PDF を読むのに使っていこうか。つまり当初の予定通りか・・・。
また半年くらいして感想を書きたい。
二年くらい前から hello work という名のマイクロプロジェクトをたまにやっている。大したものではなく、実験や評価用の書捨てコードを書くたび "hello" という単一の git repository に入れて GitHub あたりに置いておくだけ。
新しいテクノロジを試してみる時、よく知らないAPIの使い方を調べるとき、ちょっとしたベンチマークをとるとき。こういうコード、むかしは ~/tmp で適当に作業したり、逆にわざわざ独立したレポジトリを作ったりしていた。前者は書いたコードがすぐどこかに行ってしまう。後者はちょっと面倒なのと、GitHub のレポジトリが増えすぎて収拾がつかなくなる。そこで間をとり細かい書捨てコードをまとめて置く場所を作ってみた。書捨てと言っても時々あとから見直したくなる。そのときコードが決まったところにあると便利。場所が決まっているとコードを書きはじめる敷居も下がる。
もともとは、何か規模のあるコードを書く元気はないけど世の中で流行ってるものを触っておきたい、せめて hello world くらいはしようと始めたもの。だから hello work. 試してみたいテクノロジが目についたら hello work レポジトリの issue に登録しておき、時間のあるときに hello world を書きコミットして issue を閉じる。
最初は単一の hello レポジトリを使っていたものの issue として記録した試したいテクノロジたちがどんどん経年劣化していくのに気づき、今は毎年レポジトリをリセットしている (hello2015, hello2016, hello2017.)
いまは新しいテクノロジを試すよりベンチマークや API の調査など地味な書き捨てが増えた。その結果を活かすのはアプリやサービスなど大きく複雑なコードなのだけれど、実験はスクラッチで小さいコードを書く方がラクだったりする。結果のコードも手元に残しやすいし。
プログラミング力のあるプログラマなら、新しいテクノロジを試すにも単一レポジトリに見合うだけのコード、TODO リストや Wiki くらい規模のあるものを書いたり、逆にちょっとした量の実験コードを躊躇なく書き捨てるのだろう。自分は力が足りず、こういう助けが必要になった。
新しいテクノロジを試すといっても Hello world くらいじゃ何もわかんないでしょ、という指摘はまあまあ正しい。一方でインストールや設定が面倒だとかやたら遅いだとかドキュメントが陳腐化して合ってないだとかエラーメッセージが暗号的だとか、わかることも少しはある。何もやらないよりはいい。だから細かい時間はあるもののまとまったコードを書くガッツがない虚弱諸氏は hello work からリハビリするのも良いと思う。細かいコードを書いてるうちにまとまったコードを書きたくなることもあるし。
Medium のカスタムドメイン、今後は課金が発生するらしい。ただし月額とかではなく最初に $75 のみ。そして自分は early adopter ということでタダにしてもらえるそうな。まあ後から金よこせとかいわれても不愉快ではあるから良い判断だと思う。bellflower.dodgson.org は Medium のカスタムドメイン対応直後に申し込んだ気がするので、実際自分はまあまあ早かったよな。
Medium, 果たして世間のブログサービスのように書き手に課金するようになるのかなあ。その判断は妥当ではあるけれど、そんなら Wordpress でよくね、という気もする。その日に備え Wordpress はエディタの出来をなんとかしてほしい。遅すぎ。
Kotlin 小技。メソッド呼び出しで receiver が null かどうかのチェックは safe call で簡単に書けるけれど、引数をチェックして null なら呼ばないという記法はない。そこで引数を receiver にするラッパを書けば良い。
fun String.addToList(list: MutableList<String>) = list.add(this)val list = ArrayList<String>()
val hello = if (0 < args.size) "Hello" else null
// Instead of
// if (hello != null)
// list.add(hello)
hello?.addToList(list)
メソッドチェインぽいのを書きやすくなって良い。なお extension method の receiver を nullable にするという狂った機能もあるのだけれど、呼び出し側で足りることが多そう。
来た！
思ったよりすぐ来たね。年末に EC2 の provisioner を用意したが無駄になるな。今の余暇 Android プロジェクトが一段落したらまた Vagrantfile を書こう。なんとなくChefとかのもうちょっと本気っぽい provisioner を使いたい気もするけれど、単一ノードを設定するだけだと明らかに大げさすぎるのだよな。
価格は・・・よくわからん。 GPU だけで $0.7/h は少し高く感じる。たぶん自分の用途だとK80は強力すぎで、もうちょっとしょぼいのが欲しいのだろう。EC2 は g2 というしょぼめなぶん安いインスタンスがあったからね。一方で計算をガンガン回して短い時間で終わるなら、分課金とあわせ結果として安く上がる可能性はある。実際に使ってみるまでわからんな。
というドメインを持っていたのだが、切れてるぞと怒られた。しまった。超ごめん。問い合わせ中・・・。UG ドメインはやたら高いので、できれば引き取って欲しいなあ。というか引き取ってくれそうではあるから頼んでみよう。しかしまずは取り返さねばならぬ。やばし。
WK の人々にまったく恨みはないが、いかんせんもう自分の生活から遠い世界の話なので放置してしまったのだった。
Blog に記事をインポートするため Hugo を手元で動かしたら色々壊れている。細々修正。ドメインをわけて新しい hugo instance を作ろうかと一瞬思ったけれどガッツがわかなかった。CI をセットアップしたりテーマをカスタマイズしたり、面倒でやる気が起きない。
などといいつつ Hugo のドキュメントを眺めていたら、いくつか Hugo がらみで使える SaaS が紹介されていた。まず CMS の Appernetic. これは要するに Git(hub) をバックエンドにできる CMS ということらしい。悪くなさそう、だけど、一方で Github のサイトでもよくね？という気はする。
もうひとつは Netlify. Static site generator 専用 CI みたいなものらしい。CDN もついてて生成されたサイトを公開できるっぽい。今じぶんは Hugo バイナリをダウンロードしてサイトを生成し結果を S3 に push するという雑なスクリプトを書いて TravisCI を使っているのだけれど、それをやってくれるということだよな。よいのではないか。気力が湧いて新しい Hugo インスタンスを作る日が来たら試したい。
Hugo 自体は自分が anemone.dodgson.org を作った頃とくらべ格段にテーマが増えていて感動。こんなオシャレってぃーなサイトを作る人たちが使うようになったとは、流行ってるなあ。なお自分は若者 @deeet 氏が使ってるのを見て真似しただけ。特に先見の明があったわけではい。そしてカッコいいテーマたちを選ぶガッツがなく雑な CSS を書いて終了。
コンピュータの世界には、来るぞ来るぞといいつつなかなか来なかったり、来たはいいけれどぱっとしなかったりすることがよくある。次世代ナントカみたいの。それをハイプと呼ぶ人もいるけれど、ぱっとしないにしろ来たものをハイプ呼ばわりするのも品がない。生焼けの約束とでも呼んでみたい。
機械翻訳と英語学習に関する議論を目にして、この生焼けの約束を思い出した。
機械翻訳はさておき、一般にこの来るかもしれないけれどまだ来ていない生焼けの約束を前にどんな態度をとるべきなのだろう。テクノロジ産業に生きる身として、ただそれをハイプと無視するのは正しい態度ではなかろう。一方で約束が叶う前提があるかのように話をするのも浮ついて見える。慎重に、といった玉虫色の答えも判断の助けにならない。
プログラミングに置き換えてみる。pre-1.0 のプログラミング言語やライブラリをどう評価するか。使ってみるしかない。自分の主たるプロジェクトで使うべきか。場合による。不安定で新しいコードを仕事で使うにはそれなりの覚悟がいる。使う以上は積極的にバグレポートしたり、自分で直したり、クリエイティブに欠点をワークアラウンドしたり。それが有限のリスク予算を未来の技術に投じる覚悟だろう。Dogfooding の精神と言っても良い。
機械翻訳を頼れば英語学習はいらないと主張したいなら、機械学習を dogfood するのが良いのだろう。英語は読まず、常に機械翻訳を通して読む。英文は書かず、常に日本語を機械翻訳する。そうすればきっとテクノロジの限界がわかるし、逆にテクノロジの使いこなしも長けてくることだろう。その向こうには英語学習のいらない未来、そして機械翻訳を使いこなす学習の必要な未来が、待っているかもしれない。いくつか翻訳の例文をみただけで機械翻訳の未来を判断するのは、サンプルコードだけからプログラミング言語を判断するようなもの、かな。
自分には機械翻訳を dogfood する覚悟はない。機械翻訳の約束が叶わないと思っているからではなく、単にリスク予算がないから。だから自分には機械翻訳に関する未来予測はできない。仕方ない。未来はわからないもの。
一方で、自分は未来を dogfood するためのリスク予算をきちんと使い切っているだろうか。まだだいぶ余っている気がする。保守的で億劫がりな性格が腰を重くしている。テクノロジ産業従事者として生焼けの約束たちを摂取しないとなあ。