Book

コロナ禍に突入して丸２年。よく散歩をするようになりました。基本在宅ワークなので、意識的に散歩しないとさすがに健康リスクが高いからです。 散歩は考えを整理するのにもとても良くて、直近の課題への良いアイディアが出てきたり、寝かせた課題への解決策がふっと浮き上がってきたりします。[2021-01-05-1] でも書いた件です。馴染みの曲を聞きながら、いつもと同じコースを歩くと、特に効果的です。 それと相反してはしまうのですが、最近はそれに飽きてしまい、散歩中に技術系や格闘技系、歴史系の Podcast をよく聞くようになりました。ちなみにインプットモードになるので、思考の整理にはなりません。(^^; そんな中、格闘家の青木選手 きっかけで Voicy の存在を知り、他に聞くものないかなーと探して見つけたのが、佐々木俊尚さんの Voicy でした。 佐々木さんは @sasakitoshinao での朝のキュレーションが有名なジャーナリストで、私は 2011 年ごろからフォローしていたと思います。※ よくアンチが湧いていますが、そんな変なことは言ってないと思うんだよなあ。 私、朝はツイッターをあまり見ないので、佐々木さんとは一方的に疎遠みたいになってました。そんなこんなで懐かしい気持ちで聞き始め、とうとう過去の放送を全部聞いてしまいました。放送開始は去年の 9 月で、佐々木さんは毎朝 Voicy を配信しているので、それなりの数です。 そんな佐々木さんが本を出しました。お礼の気持ち半分、佐々木さんの情報収集方法を知ること半分で購入してみました。 読んだ感想としては「良い本だとは思うけど、マッチする人とそうでもない人がいると思う」かなあ？ 私の情報収集方法は、佐々木さんほど深くはありませんが、似たりよったりです。肝心の「マルチタスクワーキング」は、ちょっと使わないかなあ？なんでだろう？ 私がプログラマーだから、割とガッツリしたタスクが多いから？会社員だから、請求書作るだとかの細かいタスクが少ないから？ ※ 過去にポモドーロやタスクシュート [2016-10-26-1] は試した上での感想です。 だいたい毎日、仕事を始めたら溜まった Slack 読んでウォーミングアップして、あとはそれなりの大きさのタスクをガーッと処理する感じです。不惑の年はとうに越しましたが、集中力が続かない悩みはあまり感じたことはありません。 あ、キリが悪いところで止めるテクニックは、プログラマーの間ではテストを失敗させた状態で作業を止めるテクニックとして知られていて、私もたまに使いますね。 一方でビジネス職の人には、情報収集方法や仕事の仕方は参考になるかもしれません。Feedly, Pocket, Twitter（のリスト）など、存在や良さげな使い方はプログラマーよりは知らないかもしれませんし、タスクの粒度は小さく、種類は多い印象があります。 ということで、気になる方はポチッとすると良いと思いました。 ここまでで、私ひとつ嘘をつきました。 「『読む力 最新スキル大全』を読んだ」と書きましたが、実際には Fire HD 8 の「Kindle 読み上げ」で全部聞きました。読んでいません。皮肉みたいになって、なんだかすみません。 「マルチタスクワーキング」は集中力など要らない、時間を細切れに使えという提案ですが、聞くという解はあると思います。 さすがに私も本を読む集中力は頻繁に切れます。Twitter は見ちゃうし、格闘技系 YouTube も気になる。 そんな課題がある中で、Podcast や Voicy は異様に捗っていました。どうやら今の生活にマッチしていたようです。 だったら本も聞いてしまえば、集中力が切れる課題を解決できるかな？と試した最初の本が『読む力 最新スキル大全』でした。伏線回収？ もしかしたら、佐々木さんの Voicy を聞いているうちに「集中力なんか要らない」という仮説を認識し、それと Podcast や Voicy が生活にマッチしていることがうまく結びついて、課題を解決できたのかもしれません。 などと、この記事を書いていて思いました。 「Kindle 読み上げ」を使って、どのように本を聞いているかは、近々記事にする予定です。いろいろあって大変でした。(^^; ではまた明日。

昨日、職場の同僚から教えてもらった、昨日公開されたこちらの本を読みました。 GitHubセキュリティ Organization運用のベストプラクティス 著者は @tmknom さん。[2019-05-07-1] に読んだ『Pragmatic Terraform on AWS』改め『実践Terraform 』の著者でもあります。 今の会社は 2014 年から GitHub を使っています。当初は全部分かりまっせ！という設定ボリュームでしたが、時を経てものすごくてんこ盛りになり、把握しきれない設定項目も増えてきました。 本書によって、それらの棚卸しが出来た気がします。 本自体のボリュームは大きくないので、流し読みすることも出来ますし、適度に GiHub Docs へのリンクになっているため、ガッツリ読むことも出来ます。 いたく感動したため、少額ながらサポートさせて頂きました。(^^) 欲張りすぎずにコツコツ改善していくことが大事だと、自分をリセット出来た気がします。

職場の同僚が勧めていたので遅ればせながら読みました。私が 20 年近くかけてたどり着いた技術（未だに不完全です）を、この本で習得出来る人が羨ましいです。 仕事で少しでも文章を書く人全てにオススメします。ブログを書く人にもオススメできます。反対に、物語を書くための技術ではありません。 欧米では論理的な文章はパラグラフを使って書くそうです。パラグラフで書けば各パラグラフの先頭文をつまみ食いする、流し読みが出来ます。副次効果として、速読出来る文章になります。もちろんじっくり読むことも出来ます。論理的な文章は物語などと違って、関係者以外は流し読みしたいことが多いですからね。 特筆すべきことは、この本自体がパラグラフで書かれていることです。流し読みできます。しました。 パラグラフを適切に使っていれば、文字どおり見た目が良くなると感じてきました。良いメールやブログを書けた時は、見た目に惚れ惚れして何度も眺めたものです。 社内の日報や手順書、インシデントレポートなどの文書に目を向けると、なんでも箇条書きにされていることが多い印象です。関係性がないものが羅列されており、すごくネストしていることもあります。 パラグラフで書けば良いのにと、よく思ってきましたが、今まで説得するすべがありませんでした。これからは「この本読んで」で良さそうです。私もこれから意識的にこの本の技術を使います。 プログラミングにも通じそうです。悪いプログラムは全部読まないと理解できませんが、良いプログラムは先頭の一文（interface）を読めば何となく理解できます。 同じ著者のプレゼン版もあり、Kindle 版は 330 円割引だったので積みました。いつか読もう。あかん…。

以前から地政学には興味があったのでポチって読んでみました。 子供向けの本で、漢字には全部ルビが振ってあります。でも大人向けの入門書としても良い気がしました。久々にさらっと読めて良い気分転換になったし、地政学の基礎の基礎を知れた気がします。 日本って、ランドパワーの中国にとっては海に出ていくための邪魔な蓋でしかないのかー。 追々、他の地政学の本も読んでみよう。

２ヶ月くらいかけてようやく読み終えました。ビジネス書を読み切れたのはいつ以来ぶりだろう？ NETFLIXは「能力密度を高める」ことを最優先にしており、そんな超優秀な彼らに「個人における最高水準の報酬を払って」います。 しかも、会社として成長できる環境を用意しているので、他の会社にも引き抜かれづらい理屈らしいです。ペパボのあんちぽさんが書いてた「いるだけで成長できる環境 」を思い出しました。 その原資はそれほど優秀でない人を解雇して確保しているとのこと。日本だと簡単に解雇できないみたいなので、アメリカの法律を最大限に利用しているのかな。NETFLIX の日本法人だとどうなっているんだろう？ NETFLIX ではピラミッド構造ではなく、分散型のいわゆるティール組織なんだと思う。[2019-08-13-1] に読んだ橋本さんの本の中で、大阪市はピラミッド構造でないと無理、ティール組織は絶対無理だと言っていたが、「能力密度」の高い/低いの話だと理解しました。 そして能力密度を十分に高めた状態で、「情報に通じたキャプテン」に意思決定を完全にお任せする。上司は一切意思決定をしない。そのキャプテンはコンテキストをきちんと理解し、さまざまな立場の人からフィードバックを受け、あらゆる選択肢を理解することが求められるし、協力も受ける。 割とすんなり理解できたのは、今所属しているフィードフォースの社長や人事の方が、長い年月をかけて浸透させてきたからかな？以前の私だと納得できなかったかもしれないです。感謝。 それにしても長い。長すぎます。丁寧に説明されているけど、結論を先にして、2/3 くらいに圧縮できなかったものかなあ…。物理本だと 456 ページもあったんですね。よく読み切った・・・！ そういう意味では [2020-12-20-1] の『データマネジメントが30分でわかる本 』の、読者が「30 秒コース」「3 分コース」「30 分コース」を選べる方式は秀逸でした。 しっかり読むと大変なので、ななめ読みくらいの気持ちでに読むと良いかも。まあでも良い本でした。

[2021-02-22-1] の『達人に学ぶSQL徹底指南書 第2版 』から派生して読みました。Amazon のレビューでは読みやすい読みやすいと書いてあったので、どんなに読みやすいか期待しつつ読み進めました。 「第１編 集合の代数」は確かに読みやすかったですが、「第２編 濃度」から急に理解できなくなり、「第３編 順序数」も含めてペラペラとページをめくって終了しました。 正確に書くと、SQL との関連性に期待して読み進めたが、距離が遠すぎて読むのを止めたといった感じです。焦るところではないので、そういうものだと受け入れました。 以下は第１編の自分用メモです。高校の頃は数学が好きだったので、懐かしみながらメモを取りました。 a ∈ A a は A に属する、a は A の元（げん）である a ∉ A a は A に属さない、a は A の元（げん）でない A ⊆ B または B ⊇ A A は B の部分集合である A ⊂ B または B ⊃ A A は B の真部分集合である Ø または {} 空集合 A ∪ B A と B の和集合。“A cup B” または “A join B” と読む。SQL では UNION なので、∪ は覚えやすい。...

[2020-12-20-1] にも書いた通り、去年の 4 月から SQL と格闘する毎日です。もっとも全部自分で書くわけではなく、Looker が出力する SQL を理解したり、発生したエラーやデータ不正の原因を SQL 視点で調査したり、検証用の使い捨ての SQL を書いたりといった感じです。 つまりは SELECT 文しか書かないです。しかし、SELECT 文こそが SQL そのものと言っても良いため、現在のデータアーキテクト（データ整備人）という立ち位置での学習教材を探していました。そんな中思い出したのが本書になります。 LookML 開発者としてはこの本に書かれた全てが「優先度高」ではないため、敢えて流し読みを心がけました。 その中で重要だと思ったのはこのあたりでしょうか。 ・１ CASE 式のススメ ・２ 必ずわかるウィンドウ関数 ・４ ３値論理と NULL ・７ ウィンドウ関数で行間比較を行なう ・８ 外部結合の使い方 ・１８ GROUP BY と PARTITION BY Looker が出力する SQL で見かけない気がする EXISTS, HAVING あたりは流し読みしたので、正直まだ理解していません。近いうちに読み返すと思います。 それとは別に、「第１部 ９ SQL での集合演算」は興味深かったです。すなわち、和（UNION）、差（EXCEPT）、積（CROSS JOIN）です。商（DIVEDE BY）は「諸事情」により標準化が遅れているそうです。今まで雰囲気で UNION ALL を使うくらいだったので、集合演算は自分のスコープが広がった気がしました。 「１５ 関係に始まり関係に終わる」に SQL の関係閉包性が UNIX のパイプの概念とよく似ているという記述も興味深かったです。 UNIX ではファイルがさまざまなコマンドの入力・出力になるため、（標準）出力をパイプで次々と渡すことが出来ます。SQL では UNIX のファイルはテーブルに相当します。SELECT 文はテーブルを引数にとってテーブルを返すため、UNIX と同じように次々と出力を渡すことが出来ます。これを関係の閉包性と呼ぶそうです。これを知って、SQL に一気に親近感が湧きました。...

4 月からプログラマーからデータアーキテクト（データ整備人）にキャリアチェンジして（そうなの？）、Looker Advent Calendar 2020 のこの記事で知ったので読みました。￥500 と、大変お求めやすい価格になっています。 データマネジメント知識体系 DMBOK （でぃんぼっく）の独自要約とケーススタディ集です。全 11 章それぞれで 30 秒、3 分、30 分コースを選ぶことが出来るので、ざっと読むのもじっくり読むのも自由な点が秀逸です。 DMBOK 自体知らなかったので、取っ掛かりにはとても良い本でした。SLA はいずれ決めようかなーとか思ったりしました。

4 月から Looker という BI ツールを使って、ウェブ広告の媒体数値や計測数値などの分析や可視化をすべく、日々取り組んでいます。 ちょうど先月社内勉強会でそんな話をしました。 現在扱っているデータは Web アプリケーションで扱うような、正規化されたきれいなデータではありません。NULL は頻繁に出てきますし、サブクエリ等でゴリッときれいにしてキャッシュする処理も書いたりします。いつの間にか想定外のレコードが入っていて、定義を変更することもあります。 今までこのようなデータに向き合ったことはなかったので、こんなスキーマで良いのかなあ？とか思いながらの毎日でした。 そんな中、数年前に 94 ページ目まで読んで挫折したこの本が頭にちらついていました。 以前はふわっと読み始めたと記憶していますが、今回は割と明確な課題があります。今回は挫折しなさそうな気がしたのと、何かのヒントを期待して読むことにしました。 結論から書くと P155 に明確な答えが書いてありました。 リレーショナルモデルに適合しないデータをテーブルを用いて格納する場合は、リレーショナルモデルの原理原則に従う必要はまるでありません。そのようなテーブルでは、NULLを用いてもかまいませんし、正規化をする必要すらないでしょう。 ここを読むまでは、仮にリレーショナルモデルの原理原則に従うのだとしたら、すべてのカラムで NULL を許容しているテーブルを ETL 等でリレーショナルモデルに適合したテーブルにクリーニングするのかなあ？でも現実的ではないなあ？など考えながら読んでいました。なので、急に答えが降ってきたようでした。 SQL はリレーショナルモデルを扱うことが得意ですが、そうでないものも扱って良いと力強く書いてあります。もちろん用法用量を守って。 特に目の前の課題が解決したわけではありませんが、なにか光が見えた気がしました。 他の話も一応書いておくと、理論だけあって全部を理解するのはかなり難しく、特に第２〜４章は全く頭に入ってきませんでした。数年前はここで挫折…。 ただし、第１章の SQL と集合の関係については比較的容易で、私が数年前に読んだ時は SQL への向き合い方が変わりました。気になる人は第１章だけでも読むと良いかもしれません。他も第９章の履歴データや第１３章のリファクタリングなども。 なにか課題を抱えている人は、あまり気負わずに流して読むと良いかもしれません。

【ダウンロード版】AWSの薄い本　IAMのマニアックな話 - 佐々木拓郎のオンライン本屋 - BOOTH 少し前に Twitter で流れてきて買ったのかな。最近 AWS 等の権限まわりに課題を感じることが増えてきたので読んだ。デザインパターンやセキュリティ、運用方法など、参考になることが多くて、読んで良かった。 開発者用の IAM User の権限はやっぱり難しいみたいで、ああなるほどと思ってみたり。 仕事では開発用の共通 IAM User development を作って、.envrc 経由で使っているんだけど、さすがにドンピシャの解はなかった。 本当は開発者ごとの開発用 IAM User（例: masutaka-devel）を作って、共通 IAM User は使わないほうが良いのだろうなあ。開発者ごとの通常 IAM User（例: masutaka）は作っているんだけど。 CloudFormation によるコード管理にも触れていて、IAM Group や Role までは管理するけど、IAM User は管理しないとのこと。なぜなら IAM User は一度作ったらお終いだから。なるほど。 CloudFormation はまだ直接使ったことがないので、本書にあるようにハードルが低い IAM から始めるのは良いと思った。 IAM Policy を使った MFA の強制もやらないとな。そういえば他のチームはやっていたな。 P.S. .pdf 以外にも .epub か .mobi 形式も欲しかった。気になった箇所にマーカーやメモを付けたかった。目次からの移動も出来ないので不便。 追記(2020-03-15): Kindle 本発売されたようです。 Kindle本の販売という実績解除しました - プログラマでありたい