IT と全然関係ない話。
たまーに「このニュースのこの数字は覚えておきたいなー」と思うことがあって、そういう時どうしようかなーと思ってたけど、ささっとブログに書いておくことにした（ブログ更新頻度維持のためにも）。
今回はこのニュース。
まとめると、
という話。
1 番目も 2 番目もそれなりにインパクトあるなぁ、と思ってたけど、3 番目は特に印象深い感じ。
確かに都内のコンビニやファストフード店のバイトの人ってほとんど外国人だもんね。
Go を触っててデバッグビルドしようと思って調べる。 いたるところで次のようにしろ出てくる。
go build -gcflags '-N -l' ...
で、この -gclags と -N と -l は何なのか。
コンパイルツールに渡す引数を指定できるフラグ
-gcflags 'arg list'
arguments to pass on each go tool compile invocation.
ref: go - The Go Programming Language
それぞれの意味は次の通り。
-N: 最適化オフ-l: インライン化オフ-N
Disable optimizations.
-l
Disable inlining.
『Androidを支える技術〈Ⅰ〉 ~ 60fps を達成するモダンな GUI システム』を読みました。
Androidを支える技術〈I〉──60fpsを達成するモダンなGUIシステム (WEB+DB PRESS plus)
単純にとても面白かったです。
昔、Web ブラウザのレンダリングエンジンをいじっていた頃があって、ちょっとだけそのときのことを思い出した。 ツリーがあって、それをレイアウトして、描画ライブラリに投げて、その先が GPU で、っていう一連の処理とか。（ブラウザだと DOM Tree と Render Tree が別だったりしたね）。 大して理解もしないままその世界から離れてしまったけども。
思い出話は置いておいて、この本の何がすごいかというと、
というところ。
知識を文字にする時って、実際にアウトプットすることの数倍の知識が必要だと思う。 だから、この筆者はこの本に書かれた数倍の知識を持ってるんだよなーと思って、すごいなーと思った（小並感）。 というか、書籍にまとめるレベルになると10倍くらい必要かもね、、、
HWC と GPU 周りはとても感心して、とくに SurfaceView の仕組みはなるほどーと思った。
図にするとこんな感じ（本から引用） ^(1)
うーん、仕組みもよくできているし説明もすごく分かりやすかった。 （gralloc とかなんだよって話だけど、それは本書を読んでください）
(1): 有野和真．『Androidを支える技術〈Ⅰ〉~ 60fps を達成するモダンな GUI システム』，技術評論社，2017．図 6.16（p.250）．
この本を読むとなんとなく Android が理解できた気分になれる。
結局、得られるのは気分だけなんだよね。 当たり前だけど。 実際に自分でコードを追ってデバッグしてってやらないと本当に使える知識/技術にはならない（少なくとも自分にとってはね）
だけども、このなんとなく理解出来た気になるのはけっこう重要かなぁという気もしている。 どこかに誰かも書いていたけど、例えばクラッシュログを見ていて、
うーん、この ViewRootImpl.java ってシステム側だからなぁ、、、とりあえずクローズかな、、、
と思っていたのが
そういえば、ここらへん本に出てたし、ちょっと見てみるかな（ｷﾘｯ
という根拠のない自信に変わったりする。
そう思ってコードを読んだところで、なかなか結果は変わらないんだけど（だって変化したのは気分だけだからね）、こういう姿勢の変化は結構重要だったりする。 めげずにコード読んでるとたまーに結果が出て幸せになれたり、そもそも実際に読んでみないことには知識も得られないままだからね。
Android に対して「まあ、ちょっとコード読んでみるか」というメンタリティが持てるようになったことが、この本を読んで得られた最大のポイントかな。 あとは普通に読んでて楽しかったです（2回目）
Vol. 2 も出ていて、話題的にはこちらの方が興味があるので読むのが楽しみー。
Androidを支える技術〈II〉──真のマルチタスクに挑んだモバイルOSの心臓部 (WEB+DB PRESS plus)
The Pragmatic Programmer の Chapter 8. Pragmatic Project を読んだ。内容は次の通り。
他人の期待を正しく理解することが非常に重要という話。結局、プロジェクトは誰かの期待に応えられているかどうかで判断されるわけで。
コンサルタント業界では "Expectation Management" なんて言葉もあるようだ。この本では「俺たちはそこまでしろと言ってるわけじゃない。ただ、顧客の期待を正しく理解しよう」と説いている。
Tip 69 Gently Exceed Your Users' Expectation
そして、できればその期待を少しだけ上回ろう。Gently というのはとても絶妙な表現なんじゃないかなと思った。それくらいなら、勘違いしてユーザーの期待から大きく離れてしまうこともないだろうからね。
今年の頭くらいから読み始めて、中断して、帰りの電車でちょっとずつ読み進めてよーやく読み終わった。やはり英語の本を読むのは時間がかかる…。
全体を読んだ感想としては、こんなに頑張って読まなくてもよかったかな、という感じ。日本語版をぱらぱらと一週間くらいで読めば十分、という感覚ですね。
The Pragmatic Programmer の Chapter 7. Before the Project を読んだ。内容は次の通り。
２つほど面白い章があったので感想を書いておこう。
解くことが不可能に見える問題も、正しく制約を理解すれば簡単に解けることもあるよ、っていう話。
ここでのポイントは課された制約をきちんと認識して分類すること。分類は、
という単純な二種類で充分。私たちは「必ずしも守らなくてもよい制約」を「必ず守らなければならないもの」だと誤認してしまうことが多い。この誤認に気づくと、問題が一気に解決することがある。
闇雲に何かを始めるのではなく、始めるタイミングを見計ろう、という話。
プロの曲芸師は自分のタイミングを知り尽くしていて、すべての条件が揃うまで静かに待っている。そして、タイミングが来たと感じたら一気に勝負に出る。プログラマも何かの作業をする時はタイミングを見計らうべきだし、また、その直感を鍛えるといい。
「タイミングを見計らう」っていうのは正しく準備することにも繋がるかなぁと思った。何かに向けて準備することはとても大事だなぁ、と最近強く感じる。
いつかだったか、テレビで凄腕の心臓外科医が、手術のヤマとなる血管を切り取る場面で「ここにたどり着いた時点で、僕の勝ちは決まってるんですよ。ここにたどり着くまでが仕事なんですよね。」と言っていて、たしかになーとは思った。
CODE COMPLETE にも、
ニ回測って、一度で切る
という格言が紹介されていて、コーディングにも似た側面はあるんじゃないかなーと思った。
The Pragmatic Programmer の Chapter6. While You Are Coding を読んだ。 内容は次の通り。
印象に残る章がいくつかあったので書き残しておこう。
この章は、「自分が書いてるコードをちゃんと理解していますか」というような内容だった。
最近、以前よりも自分の書いたコードに自信が持てるようになったなー、と思っていて、『コンパイルする回数が減った』とか『一発でうまく動くことが増えた』とか、そういうところで開発に効いてきている。
いくつか要因はあると思うけど、大事なことの１つは「何を期待して目の前のコード片を書いているのかを常に意識する」ということだろう。プログラマは何かしらの『期待』を持っていて、それを実現するためにコードを書くわけだけど、どのコードが何の期待を満たすのか、自分の中でちゃんとマッピングさせておくのがとてもよい。コードに自信が持てるし、コードの理解につながる。
これには別の効果もあって、自分の『期待』をただしく理解しておくと、すごくデバッグが捗る。バグはたいていの場合、何らかの『期待』と異なる挙動をしているから発生する。だから、『期待』とコードのマッピングを持っておけば、必ず最後にはバグの原因にたどり着ける。まあ、たまに期待自体が間違ってたりするし、現実はそんなうまくいかないけど、バグ解決の確率はだいぶ高まる。
あとは、この『期待』と『コード』のマッピングはなるべく小さく保っておいて、それをベースにして大きなビルディングブロックを作ってくと、とてもいいコードが書けるんじゃないかなぁと感じている。
この『期待』ってのは『意図』とも言い換えられるかなーと思ったりして、そうするとこの章の言いたいこととつながるよなーと思った。
これは「ウィザードで生成されたコード使うならちゃんと中身読もうね」という話で、とても説得力があった。
ライブラリの場合、ライブラリ側のコード把握する必要はない。正しいインタフェースが切られていて境界がはっきりしてるからだ。
一方、ウィザードによって生成されたコードは、私たちのコードに直接入り込んでくる。「すぐにウィザードで生成されたコードをいじることになるから、理解してないとひどいことになるよ」というのはその通りだと思った。
ちょっと前、と言っても数ヶ月は経ったけど『サピエンス全史』を読んだ。
DEEP WORK を書いた人のブログに紹介されてて、ふーん、って思って、ぐぐったらどうやら邦訳が出てるらしい。 たまにはこういう読み物系も悪くないか、と思って読んでみた。
人類という種としての歴史、すなわちホモ・サピエンスという種の歴史が書かれている。
著者によるとホモ・サピエンスの歴史には3つの転換点があったようだ。
これらの3つの革命をベースにさまざまな話題がちりばめられた本だ。
最初の認知革命から農業革命あたりの話が楽しく読めた。単にその時代あたりの歴史（数万年前）をあまりに知らなかったから新鮮だっただけかも。
狩猟時代の人類はとても生活レベルが高かったというのは面白い。まだ人口も少なく、食料や衛生面で困ったら移住するという手段があり、1日のうち少し狩りをしたらあとは自由に過ごしていたようだ。一方、農業が栄えてからは、人口も増え、農作物が不作になるリスクを抱え、定住による衛生面の悪化で苦労し、年中作物の面倒を見なければならなくなり、挙げ句の果てに、階層の高い一部の個体のために育てた農作物を献上しなければ生きていけなくなった。ここから「人類は本当に幸せになったのだろうか」という問いにつなげるあたりはなかなか。
一方、科学革命からの資本主義がどうとかってところは思ったほど面白くなくて、別に考え方・とらえ方は間違ってるとは思わないんだけど「ふーん」という感じ。資本主義についてから最後にかけての展開がこの本を際立たせてる要因だと思うのだけど、自分にはあまり響かなかったな。そこらへんで仕入れた知識を列挙してるだけ？と思ってしまった。
最後に、
ひょっとすると 、私たちが直面している真の疑問は 、 「私たちは何になりたいのか ？ 」ではなく 、 「私たちは何を望みたいのか ？ 」かもしれない 。この疑問に思わず頭を抱えない人は 、おそらくまだ 、それについて十分考えていないのだろう 。
って投げかけてきて、「あっ、はい」ってなったところで本は終わった。
Amazon の 2017 年のビジネス書大賞にも選ばれてたりして、これビジネス書？って思ったりしたけど、話題の作品なのは間違いないようですね。
(c) The King's Museum
