DroidKaigi 2018 まとめ #droidkaigi

「ブログを書くまでが勉強会だ」って古い言葉もあったなとちょっと思い出しつつ。qiitaに書こうかとも思ったけどポエムっぽくなりそうだったのでこっちで。

自分が聞いたセッションのまとめと会場の雰囲気のまとめを作っていこうと思います。

セッションのまとめ

kotlinアンチパターン

Kotlinアンチパターン

感想

kotlinは便利で機能が多いので色々と使ってみたくなるが、あんまりやるとよろしくないよねって感じ。詳しい解説は資料を参照すればいいと思うので、ちょっと思い出したことを1つ。

late init を使うか lazy を使うか

プロパティをlateinit varにすることでインスタンス初期化時にプロパティを初期化できなくても、Nullableにすることなくプロパティをクラスの中で利用できて便利。例えばfindViewByIdなんかの結果得られたViewのインスタンスをlate varにしておくのはよくあるパターンだと思う。

その一方でval by lazyも便利で、kotlinのDelegated property を利用することで実現している遅延評価の機能なんだけど変数をvalで宣言できるのが嬉しい。

どっちを使うのが正しいのか判断に困ることもときどきあって、資料中にもあるようにfindViewByIdをby lazyのクロージャの中で実行した結果、Viewの再利用に対応できない地雷も踏んだ。

lazy valをどこで使うかと言えば、例えばRealmやRetrofitのような初期化にコストがかかるとされているオブジェクトの初期化だと思う。ただ、リソースの解放やFragmentの場合、再利用されることも考えなきゃいけない。

onStopでRealm.closeしたあとでActivityやFragmentが再利用されてclose済みのRealmにアクセスしてしまうなんてこともあった。このあたりを防ぐならスコープを広げるか狭めるかになるのでやっぱりby lazyを使うところじゃないかもしれない。

Applicationのライフサイクルで管理されるReamなどの場合は初期化のタイミングをアプリが起動したタイミングから適切にずらることは意味があると思う。

Androidの場合、UIのコンポーネント内でby lazyを使って初期化を行うパターンが使える部分は少ないかもしれない。

Inside Android Architecture Components

Inside Architecture Components // Speaker Deck

感想

昨年の Google I/O で公開されたけど、今のところ業務で利用をしたことは無かった Android Architecture Component の中身の解説。ありがたいありがたい。

Android のライフサイクルはかなり複雑だという感覚はみんな持っていると思うけど使いこなせないと「お前、そんなのもできないの？」みたいな空気感がある気がする（気のせい

Architecture Component の LifeCycle コンポーネントの導入で多少はマシになるかな？と思った。リソースの管理をActivityのライフサイクルに対応して行う必要がある場合、Activityから完全に分離したところで実現できるようになるためコードの複雑化を抑えられるだろう。

ちなみに、自分は以前はonCreateやonStopを定義したinterfaceを作り、その実装にリソースの管理を行わせてActivityのプロパティにもたせ、Activityのライフサイクルコールバックで呼び出していたりした。

interface LifecycleResource {
  fun onCreate()
  fun onStop()
}

class NetworkResource: LifecycleResource {
  lateinit var restService: RestService

  fun onCreate() {
    restService = //初期化
  }

  fun onStop() {}
}

class Activity: Activity() {
  val resource = MutableList<LifecycleResource>()
  
  fun onCreate(saved: Bandle) {
    resources.add(NetworkResource())
    resources.forEach { it.onCreate() }
  }
  
  fun onStop() {
    resource.forEach { it.onStop() }
    resource.clear()
  }
}

こういうのを自前でやる必要がなくなったことに意味がある。

また、ViewModelというコンポーネントがどうなっているのかは調査の必要性を感じた。Activityと一対一になるコンポーネントだけどActivityのライフサイクルより長い期間生存ができるので、画面回転のタイミングでデータが失われないということ（だと思う

あとで出てくるけど、MVIパターンによるアプリの設計実装を行うときにも重要なコンポーネントとなっている。ただ、Activityのライフサイクルよりも長い時間生存している部分についてはまだ自分の理解が足りていななって思った。画面回転のときでもActivityはonDestroyがコールバックされるけれど、それはActivityの「破棄」としては認識されないってことなんだろうな。ActivityThreadとかActivityManagerServiceと連携して難しいことをやってるのか？そのうち調べる。

Android における Model-View-Intent アーキテクチャ

Android における Model-View-Intent アーキテクチャ // Speaker Deck

感想

Androidでも、こんなReduxみたいなことができるようになってたのか〜（小並感

割と長い間、雰囲気でReactiveXというかRxJavaを使ってきたけどこういう風に使うのか〜ってちゃんと理解できたように思う。

• データの流れが一方通行なこと
• 副作用が入り込む場所が少ないこと

という点でこのやり方は良いなと思った。で、ちょっとコードを書いてみたけど気になった点もあった

• ちょっとしたことをやるのでも用意するものが増えて大変
• 画面遷移どうしようか
• プロセス間通信とかBroadcastReceiverとかのことも考えると大変かもなぁ

みたいなところ。画面遷移に関してはセッション中にも「これ！っていうやり方がない」って話だった。同時にプロセス間通信を使ってActivityとServiceで通信をするときや、BroadcastReceiverの通知を受け取る仕組みなんかをつくるときも、ActivityやViewModelで完結しないかなって思う。

こればっかりはしょうが無いのか。

でもやっぱり、設計としてはシンプルだし考えることが少なくなって良いと思った。積極的に取り入れていきたい。

はじめてのUnitテスト

Unit Testing in a Nutshell - DroidKaigi 2018 // Speaker Deck DroidKaigi 2018で登壇してきたので振り返りとか補足とか - 怠惰を求めて勤勉に行き着く

感想？

id: fushiroyama さんのハンズオンを手伝ってきた。 droidkaigi 登壇者デビュー！めでたい！！（本当はちゃんと登壇したい

人前に出て話す機会が割りと久しぶりだったのでちょっと緊張をしたけど、まあまあうまくできたんじゃないかと思った。良かったことはいっぱいあるけど、やっぱりコミュニケーションが取れたことだと思う。

ハンズオン形式で、課題に行き詰まった人のお手伝いをする以外にも実際の業務の中での困りを色々と聞くことができた。なかなか表に出てこないリアルな現場の声だと思うし、実はみんなが求めている課題ってそこにあるんだろうなぁって感想。ｲｼｷﾀｶｲセッションや勉強会はいっぱいあるけど、自分の困りにぴったりマッチできるものってあんまりないからね。

と言いつつ、当日挙げられた質問をメモったりしてたわけでもないのであんまり覚えてない。ただ、いくつかはあって（懇親会のときに聞かれたものも被ってるかも

1. Realm のテスト辛くないっすか？どうやってますか？

2. Realm やめた。気合でモック作ってもいいけどそうするとRealmそのもののテストをやる感じになるから意味ない

3. むっちゃマッチョなActivity、どうやってバラす？

4. 絶対に忘れちゃいけないのは一発じゃバラせないってこと。 少しずつやっていく。ネットワークやDBにアクセスをしているようなUIに関係のない部分は最初の方にやる。 その次にまだActivityがマッチョなら、すこしずつViewのサブクラスにできないかを検討する。

そんなようなことを答えた。メモっときゃよかったなぁ。

Android Studio30分集中超絶技巧100選

Android Studio30分集中超絶技巧100選メモ DroidKaigi 2018 #DroidKaigi #DroidKaigi_room3

感想

便利

Elastic Team Building

Elastic Team Building // Speaker Deck

感想

成長していくチームの中でどうやってメンバーの増員やメンバー間のコミュニケーションを最適化していったのかの話。人が少ないときに人を取るため、国籍を問わず採用する戦略とか面接の時の基準の明確化で面接を効率化するとか確かにって感じ。

振り返ってみると自分のチームでも実践をしているところはあって、会議にアジェンダを作って共有をすることは必須だしダイレクトメッセージを利用しないとかは当たり前のことだと思っていたけど、ちょっと別のチームを眺めたりするとその限りでも無かったりするので世の中大変だなぁって思ってる。

自分たちのチームはここで言うところのサバイバルフェーズを脱したのかなって思ってはいる。学習フェーズをずっと続けている感じだろうな。コミュニケーションに関する障壁は自分たちのチームではかなり低い方で、会議でもアウトプットしやすい空気感があると思っている。あとは学習フェーズの突破方法か。

Elastic Leader Ship は読んでみようと思った。

エラスティックリーダーシップ ―自己組織化チームの育て方

アプリを成長させるためのログ取りとログ解析に必要なこと

アプリを成長させるためのログ取りとログ解析に必要なこと

感想

わりとなんとなくで取ってしまいがちなログをちゃんと目的とともに取るための方法の提案。何をどう増やせばビジネスが加速するのか、様々な指標が世の中にあるので、「何を計測」するためのログなのかをハッキリとさせることは重要。

バグ探しや動作の確認という意味でのログ取得ではない。

でっかい規模のチームでやっていて、実装する人とビジネスの人が完全に分かれている場合は分からないけど、自分たちのチームのように小さくてビジネスを考えることと実装を考えることがほぼイコールの場合、仮設を立てて計測して仮設と照らし合わせて・・・って流れになるのでログの取得一つに関してもしっかりとした設計が必要だと感じてる。

試料中には便利なロガーのラッパーを作った話もあるけれど、「何を回収したいのか」がビジネスによって違うことを考えると一概に一般化とかは難しいなってふと思った。

Android案件の見積もりに現れる要素、あるいは丁寧に埋設された地雷たち

Android案件見積りに現れる要素、あるいは丁寧に埋設された地雷たち

感想

わかる〜。

最近はスマホ案件の受託をあんまりやっていないのもあって、ご無沙汰なんだけど、やっぱり「iOSと同じようにして」って言うのはよく聞く。もう聞きたくない。

スプラッシュスクリーンなんかもActivityのライフサイクルを考えるとなかなか難しい。iOSと全く同じエクスペリエンスの提供は難しいってことをちゃんと分かってもらわないと辛いよなって。

人間の管理についても難しい。っていうか、こういうのって失敗しても成功してもよっぽどのことがないと後に残らないからあんまり共有されない気がするので有り難い。

エンジニアだって人間なんだから、新しい何かに挑戦をするようなワクワクする刺激がないとモチベーションが下がっちゃうのはしょうが無い。あと、コードレビューは本当に難しい。簡単に相手の人格を破壊できるしされる。自分の心がここまで弱いのかって驚く。

本当に些細な事だけど「レビューのときは必ず褒める」とかのルールを作っておかないと人間の心は簡単に死ぬ。

All you need is isolating the domain

Y.A.M の 雑記帳: Android アプリの開発でドメイン駆動設計に取り組む話

感想

Droid Kaigi に2年間連続物で登壇するの、すごいなぁって思いました。

難しいことで有名なエリック・エヴァンスのDDDをまとめて、現場で使った内容にして頂いた形式になっていて本当に有り難い。かなり実践的というか、実際に利用をする場合を想定したコードや事例の紹介がメインとなっていて、自分たちの現場でも使いたい気持ちが高まる。

値オブジェクトの活用や、ドメイン部分を別のモジュールにすることなどできることは多いように思った。そう言えば自分も以前ドメイン部分っぽい部分を別のモジュールにしていたことがあって、結局設計が別の部分がだめだったのでやめちゃったけれどそんなに悪くはなかったと思ってる。

次にアプリ作ることがあればもう一回実践してもいいかなー？

マルチログインの実装方法

DroidKaigi 2018にて「マルチログインの実装方法」という発表をしてきた - Just for Fun

感想

アカウントごとにデータを取得するRepositoryやメモリ、スレッドなどを管理する仕組みを分けようという提案。やり方の1つで面白いなと思った。ただし、これだと同時にログインをしている状態を作り出すことは難しいなって思った。

メモリの管理については、可変でグローバルな変数はまあ怖いから使いたくないけど、非同期のコールバックが別のアカウントの物が来てしまう現象なんかはあり得るなと思った。Daggerを利用すればスコープのアノテーションを活用していい感じにすることはできそう。

あとは、アカウントを管理するものにライフサイクルのような仕組みを導入してログアウトや非アクティブ化するときにコールバックメソッドの中で非同期処理のキャンセル処理やコールバックの無効化なんかをやるのかな？って考えている。

UIテストの実行時間を短縮させる方法

UIテストの実行時間を短縮させる方法

感想

実機やエミュレータで動作する上に実際のアプリを描画するUIテストを高速化させる話。

Espressoでsleep多用しないとかのコードレベルの話から実行時オプションの話まであって詳しい。本当によく調べられている。助かる、助かる・・・。

DroidKaigi の公式アプリで espresso のsleepを多用したのは私です#droidkaigi #droidkaigi_room2

— numa (@numa08) 2018年2月9日

DroidKaigi の公式アプリについて言い訳をするなら、ViewMatcherが大変だったからってかんじになる。いい感じに目的のViewをみつけるための公文を探すのに疲れ果てて「あとはなんとかしてくれ〜」って気持ちでPR投げたら誰もなんとかしてくれなかった。

テスト関連の話はちょっとニッチ感が高い気がしていて、個人的にはテストに関して酸いも甘いもしっかりと知っておけば正しい状態で「テストをしない」ということも選択できていいかなって思っている。今後もテストに関しての情報収集をしっかりとやっていきたい。

全体の感想

今年はちゃんと公式アプリのコントリビューターになることができたし、登壇者の権利を手に入れたので少なくとも去年参加をしたときよりも何かが成長したように感じた。来年こそはセッション登壇を狙いたい。

セッション会場が去年よりも広くなったのは良かったし、車椅子のスペースがもしっかりとあって「やるじゃん、DroidKaigi！」って感じだった。

お昼ごはんの量もちょうどよかった。新宿にあるから足りなくてもすぐに近くのお店とかで補充ができるっていう安心感もあったかな。個人的なことだけど、朝ブラックサンダーを何個かかってから会場に行くようにしたのが良かった。脳のカロリー補充は大事やで。

空気感も穏やかなものだし、去年の課題だったと思う入場に関する部分もかなり改善されたようだった。やるじゃん、DroidKaigi。

その一方で会場が狭いかなーって気持ちもある。主に廊下とか。セッション間の混雑具合が本当にすごかった印象。もし可能なら廊下を一方通行にできたりすると改善されるのかな・・・？

今年のテーマは「ニッチ」が1つあったと思うけれど、それならもっとセッションの数を増やしてもっともっとニッチなやつがあっても良いな！って思った。

国内のカンファレンスではかなり規模があるものだと思うし、この規模をしっかりと運営して毎年改善しているスタッフは本当にすごい。それに、セッションの資料を作って登壇した方々もすごい。感謝の気持ちしかない。

1年後にまた会いたい。

赤いオーロラの街で

赤いオーロラの街で (ハヤカワ文庫JA)

年末にはてブのホッテントリに入っていた人が書いた小説。この匿名ダイアリーは自分も読んでが、かなり細かく書いてあるので他人の人生を追体験しているようで面白かった。

anond.hatelabo.jp

現在からそう遠くない未来、あるいは現在、初夏のある日に発生をした太陽フレアによって世界中の変圧所が破壊され停電となる「世界停電」となってしまった世界。主人公はあるWebメディアのプログラマーとしてリモートワークの実験のため北海道の斜里町にいたが、慣れない田舎の町で色々と苦労しながら人に助けられたり助けたりするお話。

もとの増田にもあるように、主人公はどうやらモデルとなった人物がいるようで、その人が太陽嵐による停電となったときにどうやって生きるだろうか？というシミュレーションとしての側面が強い作品だった。

太陽嵐が何なのか、どういった条件でそれは発生しそれはどれくらいの確率なのか、といったことは本書でも述べられているし解説でも詳しく語られている。ただし、「万年に一度、千年に一度」というスケールではある。

千年に一度の災害として、本書の中でも東日本大震災はよく引き合いに出されていた。それだけ人々の記憶に残った大きな地震だったということだ。千年に一度の大震災に対して誰も対策をしてこなかったこと、終わってしまえばあの時の空気感は忘れられてしまうこと、そして災害の発生は一瞬だがそこからの復興にかかるヒューマンリソースは大きなものであること。そう言った点が、おそらく著者の経験をベースに語られている、ように思う。

現実的な問題として、この本の中で語られるような千年に一度発生するかどうかの太陽嵐が起きる可能性は、最近の研究から明らかになってきているらしい。本の中でも語られるが、その予兆を検知し実際の災害が訪れる前に対策として、各地の変電設備を停止する選択肢も取れるらしい。その時が来たときにはたして我々は正しい選択を行うことができるのかどうか、正直な話一抹の不安は残っている。

さて、主人公は物語の中で多くの時間を北海道の斜里町で過ごし、ときどき東京へ戻ってくる。北海道の東の端にある街と日本の首都の対比が面白い。停電となってしまうとその影響を大きく受けるのはどうしても電気に強く依存している街だ。そのため、斜里町よりも東京のほうが被害としては大きい。水が出ない下水が出ない、ガスが利用できない、電車もストップ、信号も停止、冷蔵庫も使えないので生鮮食品を扱うことができない。そもそも、輸送手段や工場が動いていないので加工食品や薬の入荷もままならない。そこで東京のスーパーと言えど農家の人々が直接販売をするような「闇市」のような状態が出来上がる。

北海道は北海道で、たしかに東京都比べると電気に依存している部分が少ない。その一方で、農作物を加工する工場が停止していたりあるいは搾乳をした牛乳を加工できないため、毎日搾りたての牛乳が破棄されるという状態にもなる。農家を営む人たちとしてはいたたまれない。

これを主人公が類稀な才能で解決をしていくのかと思えば、そうでもない。彼は大体の現実に打ちのめされ、そして受け入れていく。その一方でときどき突拍子もないアイデアを思いついて、ほんの少しの改善を行う。停電後、機械が停止した農家があることを知った主人公は飛行場で足止めを食らってしまった人たちと農家をマッチングして短期の労働者になってもらうことを思いつく。また、配電ができなくなったメガ・ソーラーの施設のソーラー・パネルを一般でも利用できるように、殆どの人が「疎開」をしてしまった首都圏の家からパーツを接収し北海道の家で個人が利用できるように働きかける。

主人公が行うことは地味なんだけれど、たしかに小さな改善でそしてそれによって大体の人が救われる。復興の現場に必要なのは世界を変えるようなすごいアイデアではなくて、明日をほんの少しだけでも良くするちょっとしたアイデアなんだなと思った。

災害シミュレーション、復興シミュレーションとしては非常に素晴らしい作品で、「万年に一度、千年に一度」の災害に備えて一度は読んでおきたいと思う作品だった。その一方で恋愛要素が無理やりな感じで突っ込まれているように思えて、その点に関してはいまいちだった。

自己紹介

Shenzhen High Tour 18–21/Mar application started 次回のニコ技深圳観察会（2018年3月）募集開始しました。

自己紹介

@numa08 「ぬまぜろはち」と読みます。本名は別に非公開じゃないけど、会社や家でもこの名前で通しているのでこっちで。「合同会社コベリン」という会社に勤めていて、 Android や iOS や Unity などのアプリケーションの開発やサーバーサイドのアプリやバックエンドのサービス、ツール群の開発を行っています。最も強みのある分野はやはりモバイルアプリの開発ですが、それ以上に会社やチーム全体の業務フローの改善やシステム化を進めることも得意で色んなツールを試したり作ったりして新しいことを挑戦しています。

何やってお金を稼いでるか

会社の業務がメインで、その実態は受託開発が殆どを占めています。ただ、最近はご縁があって書籍を執筆する機会がありました。

好きで作ったもの、好きでやってること

昨年から執筆していた書籍。

numa08.hateblo.jp

Android アプリ開発者を自称しているので、 DroidKaigi という日本で一番大きい Android カンファレンスの公式アプリへのコントリビュート。

github.com

直近の活動としてはこんな感じです。

 ハードウェアのシリコンバレー深圳に学ぶ およびメイカーズのエコシステム感想

最近読みました。

numa08.hateblo.jp

「ハードウェアのシリコンバレー深セン」に学ぶ を読んだ

「ハードウェアのシリコンバレー深セン」に学ぶ−これからの製造のトレンドとエコシステム (NextPublishing)

今年の年始に旅行で深センへ行ってきた。と言ってもどちらかと言えば香港がメインで深センには日帰りで行っただけ。香港都の違いに戸惑いつつも、色々と楽しむことができた。

深センと言えば駅前から広がる電気街のイメージがった。秋葉原のラジオデパートとか駅のガード下のお店の雰囲気のビルが何個も何個もあって、今は無き秋葉原の面影を見たように思う。ラジオデパートもまだ健在だけど。深センのすごいことはそれ以上に街の中に工場があって、この街1つで物作りが完結することだ。本書は、著者の経験から、深センがどういう風に発展してきて、どうして今のようになってきたのかを著者の目線で語る。

中国で製造される電化製品と言えば、安かろう悪かろうのイメージがあった。実際、2000年頃にiPodがリリースされた前後、様々な種類のmp3プレイヤーがリリースされ、1個数千円で売買されていた。その性能はSonyのWalkmanに遠く及ばなかったし電池稼働だし、管理ソフトウェアも充実していなかった。しかし、それでも中学生や高校生だった自分には十分なアイテムだった。こういった商品が安く大量に日本に入ってきた背景には深センの当時のエコシステムがある。公開された基盤を利用し、横流しされたソフトウェアやノウハウを活用し、売れたメーカーと同じような商品を大量に生産していた、いわゆるパクリのマーケットだ。

当時の日本が、あるいは自分が中国をどう見ていたかと言えばどこか見下していたように思う。日本やアメリカのパクリ商品を作っているだけの国、真似しかできないオリジナリティの無い国、どこかおかしいもので溢れかえっている国。その頃、インターネットの文化にどっぷり浸かった事がある人なら共感をしてもらえると思うけれど、中国の音楽や製品を（日本のパクリだ）と言って面白おかしく紹介していた。

さて、そこから10年経った今、どうなっただろうか。確かに未だに類似商品は大量に出ている。その一方で世界を代表するドローンメーカーのDJIが登場し、あるいはスマートフォンメーカーの多くは深センを拠点にしている。

この10年で確立されたものがプロセスのイノベーションなのだろう。パクリ商品といえど商品は商品。しかもパクリ商品が戦う相手はやはりパクリ商品である。そのためいかに「早く市場に出して」「安く提供する」のかが必要だ（そして、おそらく速く撤退することも）。こうして生み出されたプロセスのイノベーション。製造工程を徹底的に効率化することで今につながる物作りのスピード感が生み出されたという。

日本にこういうものはない。プロセスを常に効率化しているイメージが有ると言えばTOYOTAだけれどそれもイメージだけなように思う。凝り固まった「昔ながら」の方法を振り返ることはなく、そのときに適した方法を選択しない。それが美徳とされているようにも思う。

今、日本は未だに中国を見下しているように思う。本書でも触れられているが、新規で製造を行う場合にかかるコストは深センで行うほうが圧倒的に安い。しかし、その背景には確かに人件費のやすさもあるのだけれどそれに加えて徹底的に効率化されたプロセスもまたあると思う。日本で製造を行ったときにコストが上がってしまうのは、単純に品質が高いからではない。

自分は製造業に従事をしているわけではないけれど、プロセスの効率化という非常に大切なことが10年の積み重ねの中で大きな違いを生み出すことに気付かされる本だった。

イルミナエ・ファイル 読んだ

イルミナエ・ファイル

暴走人工知能×スペースオペラ

ケイディが恋人エズラと別れた日、宇宙船団により彼らが住む辺境の惑星は侵攻を受けた。星際企業戦争に巻きこまれたのだ。 人々は3隻の宇宙船で脱出をはかるが、最寄りのジャンプステーションまでは半年以上航行する必要がある。いずれ追手の敵戦艦に追いつかれてしまうだろう。さらに、船内に危険なウイルスが蔓延していると判明する。そのうえ、船の人工知能が乗員に危害を加えようとしていた…… メール、チャットや軍の報告書、復元された文書ファイルでつづられた異色SF

新しい読書体験への出会い

ストーリーや設定の面白さはあとで書くけれど、やはりまずはその目を引く装丁から。

【すごい本】
『イルミナエ・ファイル』のゲラの冒頭のところをちら見せしますね。とりあえず、全編こんな感じ。というか、もっとすごくなります。
今後10年は『あのスゴイ本』で通じるモノを作ったという、ね。そういう気分です。https://t.co/Bm3dgtOyFb pic.twitter.com/w9PUDL30Im

— 早川書房 翻訳SFファンタジイ編集部 (@hykw_SF) 2017年9月11日

「復元された文章ファイル」の形式で綴られているため、様々なフォーマットの文章が登場する。本文中に登場するメインの3隻の宇宙船の中で取り交わされるチャットやメールでも、おそらく利用しているソフトウェアが異なることから送信者と受信者の位置が微妙に異なったりと芸が細かい。その他、艦内に配布されたという設定の告知ポスターやメール、広報など様々な文章が登場し、読む者を飽きさせない。

さて、こういった「過去に起きた事件」を読者が追体験する方法としては、日記形式による文章がある。H・P・ラヴクラフトやコズミック・ホラー体系の作品の中でよく見たように思う。ただし、日記形式の作品はあくまでも日記の書き手の主観的な事件の進行の追体験となる。書き手が知らないことを読者は知らないし、それを利用したトリックや事件を楽しむことができる。しかし、本書は様々な第3者の視点を含めて発生した事件を追うことになる。今、船の中で何が発生しているのか、知らないものもいれば、正しく情報を知った上で隠蔽するものもいる。星を追われた彼らの心境を推し量りつつ読み進めていくことになる。

復元されたファイルであることから、読者が追いかけるこの事件は何らかの結末を迎えたことが明らかな事実として読者の前に現れる。普通、読書には終わりが訪れる。本が完結しストーリーが完了すれば終りを迎えるし、ページをめくるごとに結末に近づく。しかし、この本は完結をした事件を読者は追いかけることになる。そのため、ほんの結末の到来と事件の全貌を知るタイミングが訪れることを普通の本を読む以上に意識して読むこととなった。いつもとは違う新しい読書体験をすることができたように思う。

盛々のSF的設定

ハードSFと言うには作中に登場するギミックの理論的説明は行われていないし、描画されていないと思う（設定がどうなっているのかはわからないけど）。どちらかと言うと世界観設定が面白い。

• おそらく未来（はるか昔、遠い銀河の彼方でも問題はないかもしれないが
• 星の開拓を行う企業が非常に力をつけ、星の統治を行ったり軍隊を組織する世界
• しかし、それでも（たぶん）地球を中心とする統治する仕組みがある世界観
• ちなみに、宗教を捨てたりはしていない

こういった世界の中でティーン・エイジャーは恋をして振った振られたといった話をしている。この上で、発生する大きな事件はあらすじにあるように「ライバル企業軍による惑星への攻撃」やその中で利用された「生体兵器をトリガーとするウィルスの蔓延」、そして攻撃のときにダメージを受けた「AIによる反乱」だ。命からがら星を脱出した3隻の船の中で人々は追跡を続ける敵の戦艦と、暴走するAIと正体不明のウィルスの恐怖に怯えていくのだ。

月々と発生する事件、矢継ぎ早に起こる状況の展開にずっとハラハラしっぱなし。時間のあるときに一気に読むのも面白いと思う。

結構分厚い

今朝Twitterでみたイルミナエ・ファイル買ってみました。デッドスペース勢におすすめしたい一冊。厚さが辞典並です pic.twitter.com/TyJB5UjK6E

— つかさ (@kadoya_tukasa) 2017年10月18日

定価で4,000円を超えるボリュームになっている。多分、これ普通の小説の装丁で書くと文庫本くらいの大きさになるんだろうけれど、ファイルの体裁を取っていることから良くも悪くもストーリーに対して遠回りをしていると言える。普通の小説では描画されないような領域の部分（例えば、戦闘で死んでしまった数千人に及ぶ！被害者のリスト）と言った情報が盛り込まれているのだ。そして、それゆえに読者はただの読者から、いつかどこかで発生した事件を追いかける調査員のような気持ちとなり本の世界へと入っていく。

今までとは一味違った読書体験を経験してみたいのなら本書はオススメ。

Androidを支える技術を読んだ

年明け早々、香港に旅行で行ってきた。行きと帰りの飛行機はLCCを使ったけど、日本からだと4時間くらいかかるので暇な移動時間を潰すために1年位積読してしまっていた本を読んだ次第。

Androidを支える技術〈I〉──60fpsを達成するモダンなGUIシステム (WEB+DB PRESS plus)

WEB+DB PRESS の「○○を支える技術」のシリーズはやっぱりハズレがない。この本はAndroidアプリの作り方の本でもなければ、LinuxとしてのAndroidの解説本でもない。前者の本は本屋さんに行けば沢山発売されているし、後者であれば「Androidのなかみ Inside Android」といった本がある。しかし、この本はそのどちらでもない。OSとしてのAndroidがアプリケーションを実行する際、世界のあらゆる開発者が構築したアプリをエンドユーザー目線で動かすため、どのような技術が利用されているのかをLinuxとAndroidの世界の境界線のレイヤーの低いところから丁寧に解説をしてくれる本だった。

丁寧すぎるほど丁寧だったので、若干内容は難しいなという印象。自分も、1度読んだだけでは全部を理解しきれたとは思えない。

また、アプリケーションの実装をする人が本書に書かれている内容を全て把握する必要があるのかと言えば、必ずしもその限りではないとも思った。

しかし、大体の技術スタックがそうであるように自分のレベルをステップアップさせたり、他の人が解消不可能なバグに遭遇したときに、その仕組を知っておくことは非常に役立つ。

そういう意味で、全てのAndroid開発者が読んでおくべき内容の本だと思った。ただ、書籍という媒体であるため世界のアップデートへの追従はできていない。できてはいないが、たぶん本書で書かれている部分の大部分は基本的なことなので、大きく変わることもないかもしれない。

どこかのレビューで読んだけれど、ViewGroupのメソッドとして用意されているonMeasureとonLayoutの違い、いつ呼ばれるのか2つのレイアウトパスの役割は何なのか、これらのメソッドをどのように実装するべきなのかをしっかり理解していなければこの本を読むべきだ。また、開発者がよく利用する（あるいは、高度に抽象化をして利用している)Handlerによるスレッド間通信がどのようにAndroidの内部で利用されているのかについても解説されている。

Handlerを起因とするバグはスタックトレースを追いかけていってもOSからの呼び出しになってしまうため、Handlerを利用したスレッドの情報を探し出すことがなぜこんなに大変なのか分かる。Handlerを利用する人は何に気をつけるべきなのか、あるいは他の開発者のためにどういった情報を残しておけば良いのかがわかれば、より親切な開発者になることができるかもしれない。

アプリケーションのエンジニアのレイヤーでできることは少ないのかもしれないけれど、光速なアプリケーション開発のためにしっかりと本書を読み込んで不用意に処理に時間がかかってしまう箇所を作り込まないようにしたいと思った。

ゲーム・ウォーズ 今の時代のジュブナイル

ゲームウォーズ(上) (SB文庫)

ゲームウォーズ(下) (SB文庫)

 映画公開が楽しみな「レディプレイヤーワン」の原作のゲーム・ウォーズを読んだ。

面白すぎて下巻は一晩で読んでしまった。

世界一の億万長者で世界のインフラを担うOasisの開発者が隠した遺産、イースターエッグを探すために、彼が愛した1980年代のゲームや音楽、アニメや映画を彼と同様に愛し読み込んだ少年の冒険物語。

登場する作品はリアルなものばかり。スターウォーズやスタートレックは当然、スピルバーグの映画や青春映画。日本のアニメや特撮もカバーされている。残念ながら世代が違うので全ての作品に対して私自身も知識があるわけでは無いのだけど、知ってる作品が出てくるとワクワクする。

VR空間の中にはアニメやゲームのキャラクター、それもビデオゲームだけでなくTRPGや小説の中の世界も再現されている。想像できる限り最高の遊園地だ。あー、Oasisの世界に行きたい...

SF的ギミックはVRゴーグルや関連テクノロジー、仮想空間でのアクションをフィードバックするハプティック装置、仮想空間中のYoutuber的な存在、現実の通貨よりも価値のある電子マネーetc...

楽しいギミックや展開が次々と登場してカオスになりつつもかなり楽しい。カオスで楽しい。

映画の公開が楽しみ。