@numa08 猫耳帽子の女の子

明日目が覚めたら俺達の業界が夢のような世界になっているとイイナ。

[試して理解]Linuxのしくみ を読んだ

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

普段使っているOS, Linux がどういう仕組みで成り立ち動作をしているのかをデバイスのレイヤーを含めて解説してくれている本。

以前、「Androidを支える技術I, II」を読んだときにLinuxに関する知識が全然足りてないなぁと感じたこともあって手に取った。

numa08.hateblo.jp

numa08.hateblo.jp

Androidを支える技術II」の後半では、アプリケーションのプロセス管理の仕組みを解説する章がある。その中では、Linuxのプロセス管理がどうなっているのかを解説した上で、Androidがどういうふうにその仕組をカスタマイズしたのかの解説が行われていた。この章を始めとして、「Androidを支える技術」の本の中では、AndroidがLinuxOSであるという仕組み上、Linuxの仕組みを知っておいたほうが理解が進むなと感じる章立てとなっていた。

自分はLinuxをわりと日常の中でもよく利用している。アプリケーションの運用こそは最近は行っていないけれど、1年前は業務の中でやっていた。他にもアプリケーションの開発環境をLinux上で行うことはよくあるし、今もやっている。その中で、よく発生するのが性能低下であったり、可用性の確保をしなければならないシーンだ。

アプリケーションの性能が低下したときに、一体何が起こっているのかをまずは解析しなければならない。幸い、Linuxには様々なOSの状態を表示するためのコマンドが揃っているが、それらが表示してくれる数字を理解するのはまだ人間の仕事だ。freeコマンドでメモリの使用量が出るが、様々な数字があって何を意味しているのかを知らなければならない。sarコマンドで様々な数字が出るが、一体この数字をどう読んで何をしなければならないのかを知っておかなければならない。

この本は、そう言ったアプリケーションの運用をする上でLinuxがどういう仕組でOSを動作させ、プロセスを実行し、デバイスを利用しているのかを丁寧に解説してくれる本だ。コマンドの利用方法ではなく、仕組みの解説を行うための本となっている。OSを動作させ、プロセスを実行し、システムコールを発行し処理して、デバイスにアクセスを行うことはそれだけでオーバーヘッドとなりシステムの性能低下を招く。従って、まずは仕組みを正しく理解しておくことで、どこでどういうオーバーヘッドが発生し、何を利用すればそれを発見することができるのかが分かる。発見ができたら次は対策だ。

この本は、更にサンプルコードを利用した実験もある。システムコールの発行やプロセスの実行、デバイスアクセスと言った動作を自分の書いたコードを使って実験し、観測することができる。言語としては主にC言語、ときどきPythonまたはシェルスクリプトと言った感じ。言語に関する詳しい解説はないので、一応C言語くらいは利用できる状態で読みたい本だ。

また、この本は良くも悪くも初心者向けの本だけれどLinuxを全く触ったことが無い場合にはしんどいかもしれない。基本的なファイル操作やエディタの操作、パッケージ管理ソフトの導入に関する部分については知っておいたほうが良さそう。そして、この本を読んでさらに次のレベルにステップアップをしたいと思える内容だった。

本の後ろの方に、次に読むべき本がいくつかリストアップされていたので手を出してみたい。

Linuxを使ってアプリケーションの開発や運用を行う上で、絶対に読んでおきたい本だった。

京都行った

大阪に引っ越しをして半年くらいが経過して、そう言えば以前から行きたかった京都鉄道博物館にまだ行っていないことを思い出したので行ってきた。

混むことは分かっていたので、平日を狙っていったけどそれでも入館は並ぶことになった。

ホテルが良かった

www.jalan.net

京都駅の南、徒歩5分くらいで九条の駅の手前くらいにあるホテルを今回は利用した。ここが思った以上に良かった。

内装や外装は落ち着きのある、都会的なおしゃれデザインに統一されていた。ロビー部分にはソファーはもちろん、焚き火を囲むことができるようになっていた。落ち着いた照明でリラックスできるし、しかも面積はそこまで無いけれど空まで吹き抜けになっていたので開放感があった。

宿泊者はウェルカムドリンクをサービスしてもらえるのもポイントが高い。焚き火を囲んでソファーに座り込んでハイボールを飲むと、それだけで一日の疲れが解消されていく。

お風呂上がりにはフリードリンクコーナーもあり、これもまた落ち着きのあるカフェのようなラウンジスペースでコーヒーやジュースを頂くことができた。眠り前にホッと一息をつくことができて、しっかりと休むことができたと思う。

部屋も適度に広くて清潔感のあるベッドだった。

これで、一人晩御飯抜きで6,500円だったのでかなりリーズナブル。費用対効果が最高のホテルだった。

晩御飯はリッチに決めた

ホテルの料金を抑えることができたし、今回は京都往復で交通費もそんなにかからない事を考えて、ちょっと良いものを食べようと計画していた。色々と案を出す中で上がったのが、三嶋亭のすき焼き。

www.mishima-tei.co.jp

名前は聞いたことがあったし、四条の方に遊びに行ったときに前を通ったことはあったけれど、実際に入ろうとは思ったことがなかった。でも、確実に美味しいだろうなと思ったので予約。

外食ですき焼きを食べることなんてあまりないし、外食の中でも今までにないくらいにリッチなやつなのでかなり期待をしていった。

これが、かなり最高。お肉や野菜は適量を焼いてもらえて食べるタイミングを完全にコントロールしてもらえる。最高のタイミングで食べることができた。そして、肉もでかくて分厚くてそれでいて美味しい。焼いてない状態で手のひらくらいの大きさのお肉だったけど、口に入れると柔らかくて溶けていくようだった。

これが、良い肉・・・

本命、京都鉄道博物館

先にホテルとか晩御飯のことを書いたのはこの部分の記事が長すぎるから。今回、京都旅行は1泊2日を予定していて、1日目は京都鉄道博物館に、2日目は適当に京都観光の予定だった。その予定だったのだけれども、京都鉄道博物館を回りきることができなくて2日目も鉄道博物館に行った。まさか、2日連続で行くことになるとは思わなかった。

博物館を回りきることができなくて2日連続で行くという自体が自分の中で初めてのことだったけれど、さらに2日連続で回っても回りきることができなくて、後日改めて行くことにした。

公式サイトによれば2時間くらいで回ることができると言うけれど、2日じゃ足りなかったのでかなり回り方が下手だったというか、スローペースだったと言うか。

そんなところだったけれど、その分充実した時間を過ごすことができた。

面白かったものの写真を幾つか掲載してみる。

例えば、0系新幹線の自動運転関連の装置。昔の写真で見る超大型の計算機って感じで興味深かった。運転台のところの壁の一面がこの計算機になっているのだけれど、これより前の世代の車両にはこんなものは無かったし、後の世代の車両にも無かった。後の世代の車両では、たぶん小型化に成功してもっと小さなものになったんだろうと思うけど、前の世代の車両ではそもそもこんな計算装置が無くて、いかに新幹線という乗り物が他の乗り物と一線を画する特別なものだったのかが分かるようだった。

他にも、昔から憧れたトワイライトエクスプレスが展示されている部分もあった。超高級列車として存在感があったけど、結局、一度も乗ることもなくその運行が終わってしまった。ブルートレインの全滅もあって、子供の時に寝台列車に乗れなかったことがただただ惜しいと思う。

あと、500系新幹線のエヴァコラボのものが展示されている。通常時は普通の500系新幹線になるのかな?絨毯の上に新幹線が置いてあるという状況が面白い。デザインの格好良さは圧倒的だよなぁ。

車両以外でも様々な展示があって、例えば通票閉塞機の実物なんかもあるし、しかもサイド部分が透明になっていて内部の構造を眺められるのが楽しい。この閉塞機は大宮の鉄道博物館とか大洗駅なんかにもあって何度も見たけれど、内部の構造が分かるものは無かった。

閉塞機の後ろには、実際の信号やポイントをコントロールできるシミュレーターもあって、正しく入力を行えばポイントを動かすことができる。

こういうものを全部見ていたら結局時間がなくなったので、2日目に持ち越した。

2日目で思ったことは、1日目に吸収をした知識の復習ができる環境が整っていること。入り口に展示されている0系新幹線蒸気機関車C61なんかのブレーキの構造や連結器の種類なんかを全て眺めながら見ていくことになったので、やっぱり時間が足りなかった。

2日間かけて館内は全部見たけれど扇形車庫を見るには至らなかった。

記憶も曖昧な年の頃、まだ梅小路蒸気機関車館だったころに扇形車庫は見たのだけれど今の年齢になって見るものとはまた違うんだろうなぁと思いを馳せた。

そんなわけで、まだ見足りないし、2日間かけて蓄えた知識もあるのでそれらの復習もかねて何度も何度も通いたいと思える場所だった。年間パス無いかなぁ・・・。

アルテミスを読んだ

アルテミス(上) (ハヤカワ文庫SF)

アルテミス(上) (ハヤカワ文庫SF)

アルテミス 下 (ハヤカワ文庫SF)

アルテミス 下 (ハヤカワ文庫SF)

近未来の月面を舞台に、密輸業を営む主人公の女性が不可解な依頼を受けたことをきっかけに、微妙な人間関係の人々と手を組んで月都市を巻き込む陰謀に立ち向かうストーリー。

物語の登場人物が多いのだけれど、その一人ひとりがストーリーの終盤に絡んでくる構成にワクワクした。

作者は火星の人と同じ、アンディ・ウィアー氏。火星の人のときもそうだったけれど、困難な状況に面していながらも明るい語り口と科学知識で課題を解決していく軽快なノリが楽しい作品だ。

主人公は溶接の技師でもあって、物語中に何度かこのテクニックが発揮されるシーンが登場する。月面という低重力、ほぼ真空空間中での溶接作業なんて今までの人生の中で全く想像したこともないようなテクニックを発揮する。この中でやはり作者の持つ化学の知識が発揮され、何が危ないのか、何が困難のか丁寧な解説が行われる。それでも、専門書のように小難しい内容になるのではなくテンポよくストーリーが進行していく。 主人公も魅力いっぱいだ。月面都市のアルテミスのアンダーグラウンドというか、そっち系に顔の効く彼女は誰からも愛されるタイプのキャラクターだ。関係が悪化しても殺したいほどの子ではない、いつまでたっても悪ガキのような少女のような。設定年齢よりも少し幼く感じた。あんまりリッチではないけれど、精一杯生きている感じ。そんな彼女だからこそ、街を誰よりも愛していて、それゆえに皆をまとめることができたんだろうな。

知らなかったけれど、この作品も映画化が決定しているらしい。楽しみ。

作者の構想としては、月面都市アルテミスを舞台とした別のストーリーを作っていく思いがあるらしい。次回作にも期待をしたい。

Androidを支える技術II を読んだ

組み込みOSでありつつもセキュリティアップデートやユーザがインストールするアプリケーションに対応しそれらをマルチタスクで実行し、さらにユーザのリテラシーはサーバーやPCと比べても低いであると想像される。それが、Androidに求められた要件。これを、一般的なPCやサーバーと比較して貧弱な携帯電話上に構築する必要があった。

自分が初めてAndroidのアプリ作りを経験したのは、2009年か2010年のことだったと思う。初めて本を買ってきて4つのコンポーネントを学び、コードを意味もわからず写経していたとき、なぜ画面単位をActivityと言うもので管理するのだろうか?と考えていた。それ以前にGUIのプログラミンををやったことがあるわけでもなかったので、「きっと頭の良い人が考えれば理解ができる点なんだろうな」と思って後回しにしていた。それから10年近く経った今の今まで深くその理由を考えることなく進んできた。

本書はActivityが生成されて画面に出るまで、そしてどういった条件下でActivityが破棄されるのかのプロセスをLinuxのレイヤーから順番に追いかける構成になっている。アプリのインストールが行われたらPackageManagerServiceがpackage.xmlを更新してIntentを解決できるようにし、端末がブートしたときに関連するサービス群を起動し、Activityをスタックで管理する仕組みの中にユーザが起動したActivityを含めていく・・・という流れになると言える。

更に、再生成におけるデータの保持を実現するためのBundleの仕組みについての解説もある。どうやってActivityのもつデータを一時的に保持しておくのか、再生成のときだけ復元するのかの仕組みをコードとともに紹介している。実は自分はBandleは一度ファイルI/Oが発生するものだと思っていたけど、そう言う訳ではないらしい。こう言った誤った知識が正しく訂正されるきっかけとなるのも嬉しい。

Androidソースコードに注目をした本は他にもあったと思うが、やはりこの本が別なのはLinux的部分ではなくてAndroid的な部分に重点を置いていること、そして話題とする部分を絞って解説してくれることで、注目するべきソースコードが何のかがわかりやすくなる構成にあると思う。この本で言えばActivityの起動に関するプロセスについてのみの話題で1冊が構成されている。手広くなって読者目線で何が起こっているのかわからなくなってしまう、ということが無いのだ。

Androidのアプリを開発する中で、Zygoteというプロセスを見かけることはよくある。スタックトレースを辿っていくと最後の方に現れるやつだ。あれが一体何なのかは雰囲気的にランループを作るところなのかな?くらいの認識だったけれど、その実態はアプリケーションの起動を司るめちゃくちゃ重要なシステムサービスの1つだ。今まで単語が出てきても深くは考えずスルーしていた部分についてしっかりと理解をすることで、今後のバク調査やアプリ開発でも役立つかもしれない。

この本を読んで学んだことの1つに、1つのアプリケーションは1つのプロセスになるとは限らないと言えることだと思う。Androidアプリのパターンの1つにApplicationクラスの参照ツリーの中にデータを持たせて、アプリの中からSingletonのように利用するパターンが有るように思う。しかし、Applicationクラスはプロセスに対して一意ではあるが、外部から起動なActivityやServiceの提供をしている場合などにアプリのプロセスが2つ以上になることはあるようだ。そうなると、アプリの中でSingletonだと思っていたデータは実はプロセスの中でのSingletonであるという点が問題になってくるケースがあるかもしれない。良い具体例は思いつかないけれど。

誰もが使うパターンだからと言って、そのまま心を無にして利用することの危険さを思い出した。

今一度自分の知識をおさらいして、間違えた理解がないのか、間違った考え方をしていないのかを確認する意味でもこの本は非常に有用だ。そして、それ以上に普段は意識することのないアプリよりも下のレイヤーに対する詳細な解説があるおかげで、やってはいけないパターンに思いを馳せたり、パフォーマンスを高める工夫を発見したり、バグが発生したときの効率の良い調査を実現できるだろう。

少なくとも、Androidアプリ開発を現役でバリバリ行う人には必読書であると感じている。

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で宣言できるのが嬉しい。

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

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

onStopRealm.closeしたあとでActivityFragmentが再利用されて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から完全に分離したところで実現できるようになるためコードの複雑化を抑えられるだろう。

ちなみに、自分は以前はonCreateonStopを定義した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のライフサイクルよりも長い時間生存している部分についてはまだ自分の理解が足りていななって思った。画面回転のときでもActivityonDestroyがコールバックされるけれど、それはActivityの「破棄」としては認識されないってことなんだろうな。ActivityThreadとかActivityManagerServiceと連携して難しいことをやってるのか?そのうち調べる。

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

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

感想

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

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

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

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

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

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

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

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

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

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

全体の感想

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

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

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

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

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

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

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

1年後にまた会いたい。

赤いオーロラの街で

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

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

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

anond.hatelabo.jp

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

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

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

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

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

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

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

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

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

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

自己紹介

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

自己紹介

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

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

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

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

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

numa08.hateblo.jp

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

github.com

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

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

最近読みました。

numa08.hateblo.jp