midnight in a perfect world

webエンジニアのメモ

絵で見てわかるマイクロサービスの仕組みを読む。

うーん、これも割と微妙だった。マイクロサービスのアーキテクチャを採用して現場で構築・運用するエンジニアにはあまり参考にならないかも。なにしろ、IT環境を取り巻く変化として近年のDXとかDevOpsとかの用語解説から始まるので、本編はいつから始まんのかな?と感じてしまった。確かにマイクロサービスを構成する個々のサービスの深掘りまでは期待してなかったけど、現場のエンジニアというよりはITコンサルとか上流SIerが現場のエンジニアに舐められないように読む本という感じで、そういう意味ではタイトル通り絵や図である程度概念を掴むことはできると思う。著者陣は背景知識も含めて知識量は豊富だし説明がわかりにくい訳でもないので、単純に自分が対象読者ではなかったというだけ。

後半になってDockerやkubernetesの技術的な構成要素の説明が出てきて、その中で実際のコマンドとか出てきて多少知識の整理にはなった。あとはサービスメッシュの説明の章でistioとかEKSとかを触れるサービスに携わりたいなと改めて思った。

マイクローサービスやサービスメッシュのメリット・デメリットについて簡単に解説される部分もあるけど、やはり現場エンジニアとしては抽象的すぎてあまり役立ちそうにない。少し視野を広げてみるという点では学びになる。

「軽量Alpine linuxによるDockerコンテナ構築術」を読む。

正直、期待外れだった。もう少しAlpineならではのDockerコンテナ構築ノウハウが書いてあるかなと思ったんだが、残念ながら一般的なLinuxコンテナのコマンドや操作説明に大部分が裂かれているのであまりAlpineならでは感がない。紹介されるコマンドも正直数年Linuxを管理・運用しているレベルのエンジニアだと当たり前のものしかないので、想定読者に合わなかったのかもしれない。

現場でAlpineをdockerイメージとして動かしてるアプリは結構あって、軽量でセキュアという恩恵や思想を理解してても、アプリでちょっとした操作をさせたい時にAlpineだとコマンドがなくて動かないということがあって、Dockerfile内にちまちまインストールするコマンドとかを書かなくてはいけなくてだるかったりする。そういう部分にまで踏み込んだ、もう少し実務寄りな内容だと勉強になったかなという感じ。

あとはもうちょっと冒頭のAlpineの紹介の章を膨らませて、Alpineが作られた経緯だったりBusyboxの詳細とかを掘り下げてもらえると面白かったと思う。

「ソフトウェアアーキテクチャの基礎」を読む。

最近は実現したい機能に対してどうやって実装するかについて議論することが増えてきて、ベストな選択がないトレードオフの中で決めて実装する機会が増えてきて改めてアーキテクチャについて整理したくて読んだ本。自分の中ではアプリよりはインフラやミドルウェアに関するアーキテクチャが主担当ではあるものの、そもそもそういうレイヤーで考えがちなのはなぜか?とか改めてマイクロサービスやサーバレスの構成のメリット、デメリットを考え直す学びになった。

あくまでもアーキテクチャの基礎についての紹介なので、具体的な固有名詞を挙げて実装すべきであるというような内容ではない。アーキテクトは組織の政治力学も理解する必要があるとし、システムの要件ごとの優先度を考え、アーキテクチャに当てはめてて各要件を星の数で評価していく手法なども現実的な落とし所を考えるという意味でも面白かった。

あとは結構ソフトウェアに限らず工学的なアプローチでアーキテクチャを分析する方法の紹介もあり、一昔前に誰もがベストだと思われたアーキテクチャが今では全く使われなくなった的な余談とかも挟まってて笑った。

ペネトレーションテストの教科書」を読む。

先日本書で扱われるようなペネトレーションテストの実習研修を受けたので、個人的な振り返りとしても読んでみた。面白く読めたが、かなり実務的なので、手を動かすセキュリティエンジニア的な肩書きのある人でないと若干読むのが難しいかも。

 

個人的には、読んでて固有名詞を除いては全く未知の単語は無かったと思うが、用語自体やOS・ネットワークの基礎知識だったり、なぜこのような脆弱性が発生していて防御する必要があるのかみたいな背景知識の解説がないので初心者向きではない。扱われる言語もPHPxmlWordpressやFortinet機器だったりと必ずしもIT企業全般で使われているとも限らないので「読んでは見たけど現場で活かしづらい」みたいな人もいると思う。というか自分がそうだったのだが。本書で紹介されるコードやコマンドもサポートサイトでダウンロード出来るという状態でもないので、読みながら環境構築してコマンドを実行してみる、というような検証も正直しづらい。特に厳しかったのがヤバいCVEを直接扱った「既知の脆弱性の悪用」の章で、ヤバさは伝わるのだがいきなり脆弱性の攻め方の解説となるので置いていかれる感があった。

さらに、索引がないので読み終わった後に用語の検索が出来ず、本としての体裁も良いとは言えない。

 

ただ、本書の魅力は無味乾燥な教科書的な筆致でなく、著者の想いとか好みが込められてるのがエモいと言える。実際にペネとレーションテストを現場でやっていた人間ならではの、限られた時間やリソースの中で効率的な診断するためのノウハウが詰まっている感じ。

 

kali linux自体触ったこともなかったのでとりあえず使ってみたり、nmapやrconfigやhydraやsqlmapなどさまざまな便利ツールや脆弱性診断サイトなどは本書を読んで触ってみたり自社の脆弱性を診断してみたりして、勉強になった。業界的にはかなり若いエンジニアの著者なのでこれからも応援・ウォッチしていきたい。

「事業ポートフォリオマネジメント入門」を読む。

すごく実践的で面白かった。自社サービスをやる会社にいる人間として、現場の状況を知り尽くした感じのある文体が読んでて納得感がすごかった。日本において資本コスト経営がこれまで重視されてこなかった理由だったり、制度会計に追われてきちんとした財務・ファイナンスが出来ている会社の少なさだったり、やろうとしても社内政治的にやりづらかったり、投下した資本の計測ができずデータがないとかいちいち面白い。

これまで投資に関しては面白く感じて情報収集する時期と飽きて放置する時期のムラが大きかったが、投資家というか株主が企業に対して気にする点が銀行などの債権者とどのように異なるか、などの比較説明はとても腑に落ちた。

本書で学んだことは基本知識として頭に入れておける状態にしたい。ROICとかWACCがどのような数字でどのような意味があるか、を知った上で議論できるようにしたいんだよな。日頃から使わないと忘れていくので。

ゴーイング・ダーク」を読む。

多分、木澤佐登志氏が推薦していて知ったと思うのだが、読みたい本リストに入っていた一冊。タイトル通り、過激な組織への潜入ルポもの。

timit.hatenablog.com

ルポなのでそれほど学術的。評論な感じではなく、笑えない組織の実態を描いてはいるのだが「クレイジージャーニー」を見ているようなスリルを楽しめる。本書で紹介されている様々な組織の中で、著名な人物や事件はともかく、仲間内だけで通じるような隠語で検索してもあまりヒットせず、ちゃんと地下に潜って活動してるんだなぁと感心する。となるとテック寄りの話がどうしても出てくるので、ダークウェブとかハッカー、クラッカーの生態とかと合わせて紹介されるのでエンジニア視点でも勉強になる。

読んでて怖かったのが、tradwifeという保守的な反フェミニスト女性の組織。これに関しては他の組織と多少違って普通にyou tubeで彼女たちの生活ぶりを紹介するyou tuberみたいな人もいて、オープンに「夫にしつけられること、服従されること」を望んでいてそれが本来の女性の役割みたいな話を語っていて、夫に対して「妻が反抗的な態度を取ったら公衆の面前でも暴力でしつけてください」みたいに呼びかけていて凄く怖い。you tubeでwhat woud you do?という社会派ドッキリ番組を見るのが好きなんだけど、こんな男が自分の生活圏内にいたら流石に止めると思う。

プロダクトマネジメント」を読む。

副題の「ビルドトラップを避けて顧客に価値を届ける」ための方法論を、CxOなどの経営層のレイヤーから、もっと実務的にプロダクトを形作るレイヤーまでの何度も繰り返しながら語るような内容で、それほど大きな学びはなかった。要は目的と手段が逆転してしまっていたり、局所最適化してて全体最適できていないなどの「失敗の本質」に近い読後感。ただ、著者の実際の仕事に当てはめて平易な言葉で語られるので実感は持ちやすく、読みやすい。読んでる途中も、社内の近い立場の人たちの顔と普段の仕事ぶりを思い浮かべながら読んでた。

本書で紹介されている「ミニCEO」のような感覚になってしまうプロダクトマネージャに「私の仕事は価値を生み出すことであって、自分のアイデアを形にすることではありません」とか、さまざまな関係者の注文をただ受けるだけの「ウェイター」でもない、とかは陥ってしまいがちなアンチパターンとしてあるあるだろうな、と思えるし、常に利用者の声を聞いて学び、リスクを下げるのが大事、など心構えを学べる。

実例として面白かったのが何度も参照されるNetflixプロダクトマネジメントで、「顧客に価値を届ける」ためにサンクコストを気にせず自分達のプロダクトを大幅に変えたりしてきた例を挙げており、素直にすごいなと思った。うちの会社でこういう意思決定をするのは難しいよなとも思ったり。