死んでしまったOSたちへ
自分は本の草稿に誤字脱字探しをしつつ好き勝手言う係としてちょっとだけ手伝った。せっかくなので宣伝してみる。 この本はコード読みブログやアーキテクチャ解読ブログをまとめたような体裁になっている。といっても各章バラバラではなく、本としての連続性はある。そして OS というものを包括的に解説するかわりに Android の特徴的なところ、たとえば GUI フレームワークや VM のランタイムなど、をつまみ食いしている。これは正しいアプローチだと思う。伝統的な OS の話をしだすと Android ってだいたい Linux だからね。Android に限らず、この「伝統的な OS の上にあるプラットホームのレイヤ」の中身を説明した本は少ない。 そこが面白い。 この本の欠点は文章がけっこう slippery なところ。悪い意味でブログぽいというか同人誌ぽい。ただそれは「支える技術」シリーズに共通する
TensorFlow Paper 感想
当方機械学習素人につき大して興味はなかったものの、実は Jeff Dean 案件だと気付き whitepaper くらいは読むことにした。 ぎもん: Jeff Dean といえば MapReduce や GFS を作った Google の神話級プログラマ。そんな分散インフラの達人がなぜまた深層学習に手を出したのだろう。 わかったこと: TensorFlow は、行列(というかテンソル)に特化したデータフロー・プログラミングの分散実行処理系だった。 データフロー・プログラミングとは、データを受け取り何か計算して結果を誰かに渡す、という単位のオブジェクト(ノード、カーネルなどと呼ぶ)をつなぎ合わせてグラフをつくり、より大きな計算を表現する抽象化のパターン。最近はリアクティブの文脈で目にすることが増えた。 そして MapReduce/Hadoop も今はデータフローの枠組みでコードを書くことが多
意見を持つ
今のチームのプログラマたちは、製品の機能や UX に意見を持っている。 UX デザイナがおらず PM もおとなしいプログラマ中心のプロジェクトから来た自分は、アプリやサービスの世界でデザイナや PM がどう物事を決めるのか、そこにプログラマがどう絡むのかに興味を持っていた。どうも一筋縄でない。 定例ミーティングではデザイナのモックを前にプログラマたちが細かいレイアウトや動きを議論している。各リリースの計画会議では誰かしら自分の欲しい機能を持ち出す。廊下でデザイナと顔を合わせては唾を飛ばし合っている。ランチで PM と同席するたび何かを申し立てている。 自分はそんな意見がない。開発しているアプリに興味はある。自分で使っているから良くなってほしい。でもアイデアはない。速くてバグがなければいい、くらい。 コードの書き方には意見があるし、開発プロセスやインフラにも言いたいことは多い。バグを減らした
Android らしい Java - 3. 薄い抽象
Android プラットホームの API はひどい。 プラットホームというもの一般の API デザインが時代にあわせ少しずつ良くなる中、Android は時代を10年くらい巻き戻した感がある。深い継承。でかいクラス。ヒラより多いマネージャたち。コンサーンもレスポンシビリティもテスタビリティも何もない。 モバイルデバイスには従来の Java が気にかけなかった様々な制約がある。同じように行かない。それはわかる。でもねえ。 過去にもひどい API のプラットホームはあり、人々は大きく二つの方法で立ち向かった: 一つ目は、プラットホームを無視して自分で再発明する方法。Qt や XUL, Swing みたいなクロス OS のツールキットはだいたいこの路線。二つ目は抽象化レイヤをかぶせて隠す方法。Windows API に対する MFC, WTL や SWT. あるいは DOM に対する jQuer
XML-y
久しぶりに前向きな意味で XML が口にされるのを耳にした。正確には XML-y。 巨大で messy な "MegaController" クラスを小さくテスト可能なクラスにリファクタリングするそのライブコーディング(日本語トランスクリプト)のなか、演者の Andy Matuschak はテストの要らないある種の無難なコードたちを XML-y と評した。エックスエムエリィ。 XML-y なコード。たとえば値をセットするだけ。テーブル駆動的な switch-case. あとは View ツリーの構築もそうだと思う。React 経験者なら JSX を使わずに render() を書くと思えばだいたいあってる。Android 用の Kotlin フレームワーク Anko が View の構築に使う気の利いた DSL もこの仲間といえる。 JSX や Anko DSL が成り立つのは、その処理が
Android らしい Java - 2. 寿命
寿命、ライフサイクルのはなし。(Part.1 はここ) Android の中には、決められた寿命を持つ重要なオブジェクトがいくつもある。代表例は Activity. View も Fragment もプラットホームによって寿命が決められている。 Java は誰かに決められた寿命を扱うのがあまり得意でない。多くのオブジェクトは Java 自身の GC が寿命を決める。GC があるからプログラマは寿命について悩まなくていい。そんな態度が従来の Java にはある。C++ のように神経質な寿命管理は出番が少ない。 Java でも File のような OS の資源は GC でなくプログラマが寿命を決める。Socket なんかはもう一段厄介で、相手側から閉じられると勝手に死んでしまう。そして死んだオブジェクトを触るコードは呪いの例外に見舞われる。 勝手に死ぬ Activity や View の性質は
Android らしい Java - 1. 非同期性
仕事で Android アプリのコードを触り始めはや数ヶ月。少しは理解が進んだ。 今の仕事のコードは、残念ながらそれほど素晴らしくない。その昔 Android Java にまだ慣れていなかった人々が書いたであろう古いコードが目につく。そして古いコードの昔ながらな残念さは、従来の Java とは違う Android Java の「らしさ」を描き出す。そんな話を数回にわけて書いてみたい。 第一回は非同期性のはなし。 Android のアプリはメインスレッドをブロックしてはいけない。だから色々と非同期に書く。ところが従来の Java は非同期がさほど得意でない。多くの API がブロックする。 ブロックする処理は別のスレッドに追い出せばいい。ただし結果はイベントループを通じてメインスレッドに戻さないといけない。これを綺麗に書くイディオムが、Android では最近まで確立されていなかった(Asy
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
