イラストでわかるDockerとKubernetes (Software Design plus)

DockerもKubernetesもよく知らないので概要を知るために買いました。

目的に合致していた。インフラよりのことをあまり良く知らない人が読むのに適していると思う。

全体像をなんとなく知ることが出来る。これを読んだところで運用できるかというと全くそんなことはないが、運用している人たちが何を話しているかが多少は分かるようにはなるとお 

イラストでわかるDockerとKubernetes (Software Design plus) 徳永 航平 https://www.amazon.co.jp/dp/4297118378/ref=cm_sw_r_tw_dp_x_zmz2FbNECJ73H

ユークリッド『原論』とは何か

ユークリッドの原論は、難しくて読めないということでこちらを読んでみたが、こちらも難しかった。

学生時代のように真面目に数学の文章を追いかけるつもりで読まないと何も分からない。

ユークリッドの言論よりは読みやすいとは思うが、ガッツリ数学の本なので、社会人がなんとなく読む本としてはオススメできない。

歴史的な背景なども軽く触れられてはいるが、それならば他のユークリッドの原論を日本語訳した本にもあったりするので、歴史をさらっと読みたい人は原論自体を買ったほうが良いかもしれない。 

ユークリッド『原論』とは何か―二千年読みつがれた数学の古典 (岩波科学ライブラリー) 斎藤 憲 https://www.amazon.co.jp/dp/4000074881/ref=cm_sw_r_tw_dp_x_K53ZFbH3Q0DZ9

アメリカ史 下 (YAMAKAWA SELECTION) 紀平 英作

２０世紀及ぼ２１世紀のアメリカについて記述されている。時代が近いので上巻よりは面白いがそれでも淡々と歴史が語られているという点は同じである。

産業の発展で大量に生産されたものを吸収することが出来ずに大恐慌に突入し、それを回復させたのは戦争であった。

ただ、景気が上向くと福祉に対して予算が振り分けられる様になり始めている。

第二次世界大戦においては、国民の総動員が必要とされるという特性から黒人や女性の社会への進出が促された面もあるようだ。

５０年代からは景気は上向き続け、中産階級が生まれている。社会全体が豊かになり貧困がなりを潜める時代らいい。

これらの人たちは、現代の老人世代となる人達だ。

豊かな成長は長期間は続かず、景気が冷え込むとともに社会のありようも変わる。雇用が守られることはなく貧富の差は拡大し始める。

アメリカのひどい貧富の差の拡大というのは、８０年代から続く傾向のようだ。除法技術がそれに拍車をかけたにせよ、政治的にもそのような方向に向かっていたようだ。

9.11でアメリカは一体化したかに見えたが、実際には分断し続けている。というの実際のところに感じる。

分断の種類は、人種だったり、労働者かどうかなどだったり、時代によって変わるが、常に分断と対立の国内政治という感じだ。

だからこそ２大政党制というの機能しているのかとも思う。

黒人差別も同様で、常に改善が模索されるが大した改善はしないというところだろうか。

興味深いのは、アメリカ社会にも基本的には良心があり、景気の拡大と資本の集中が行き過ぎると社会福祉に関心が向いて、大統領がそのような課題に取り組むということだ。ただし、取り組んだとしても国内の反発にあい、政権は大きな成果を残すことなく社会福祉の課題解決には至らないという点だ。

おそらく次期政権も社会福祉政策を実行しようとするだろうけれども、反発にあい実現しないのではないかと思う。

結果的に、外交に力を入れるようになり核の拡大につながらないかは懸念される。軍事予算が増えれば工場が増えて労働者に富が分配されるので心配である。

一貫しているように感じるのは、経済的な影響力を強めた集団が自分たちの利益のための決断をしていくという点だけな気がする。

とてつもない数学

面白いが、数学を知らない人が数学の面白さや美しさを感じるための本というよりは、すでに数学に触れて美しいなと感じている人が共感するための本かなという感じはする。
子供が将来読んだら面白いだろうかと思って読んでみたが、少々内容が数学好きのために書かれていると感じる。

ただ、奇数を足し合わわせていくと平方根とか
19x13の掛け算が平面図形で考えかえると簡単に理解できるようなところなどは、数学の面白さがわかりやすくかつ簡単に書かれていると思う。

 とてつもない数学 永野 裕之 https://www.amazon.co.jp/dp/447810882X/ref=cm_sw_r_tw_dp_x_RT6NFbWHZNNTH

アメリカ史 上 (YAMAKAWA SELECTION) 紀平 英作

11の国のアメリカ史――分断と相克の400年

を最初に読んだが、アメリカの歴史についての知識がなさすぎて難しかったので、入門書として読んだ。

本としては、歴史が列挙してあるだけなので、物語性はなく、退屈といえば退屈である。

ただ、黒人解放のための南北戦争だったのかというと、そうではなく、南部の独立を阻むだめの戦争に過ぎなかったとか。

北部も、奴隷制は非人道的であるが、黒人が白人と平等かというと全くそんなことは思っておらず、むしろ差別意識があり、黒人を集めてアフリカに送り返すのが良いと思っていたりとか。

黒人奴隷を所有しているのは、白人でもごく一部で、奴隷主と非奴隷主で利害関係の対立があったことも奴隷制の廃止に寄与したとか。

よくよく考えれば当たり前だが、奴隷制の廃止は、黒人のことを考えた結果ではなく、白人同士の利害関係の対立の結果として発生しているにすぎ無いというのが分かる内容ではあった。

奴隷解放後も黒人差別はのこるというかむしろ悪化するなどしている点も興味深い。また、貧富の差の問題など１００年以上前からある課題が、世界１の経済国家でも克服できていないというのは、もはや克服する気はなく、政治家のパフォーマンスの道具程度の意味合いしか無いのだろうなとか思うなどする。

そういった気づきを得られたという点では良書だと思う。

学生向けというよりは、ニュースなどをある程度見ている社会人向けかと思う。

アメリカ史 上 (YAMAKAWA SELECTION) 紀平 英作 https://www.amazon.co.jp/dp/4634423812/ref=cm_sw_r_tw_dp_x_P0xMFb21B7PK6

詳解HTTP/2

 ためにはなったけど、アプリケーションを作る立場の人はあまり学びがない気がする。

通信内容をみてデバッグしようと思ったときでも、そんなに役に立たない可能性がある。

インフラ周りを構築する際には良いのかも。という程度。

詳解HTTP/2 Barry Pollard https://www.amazon.co.jp/dp/B087JFFK9V/ref=cm_sw_r_tw_dp_x_5wSEFb21NFFFJ

おいしい昆虫記

前半は面白かったけど、終盤は息切れ感がある。

最終的に昆虫で生活が安定するところまで行っていれば、物語として楽しめたけど、まだ途中という感じ。

昆虫食自体のデータに基づいた価値を説く本ではないので、仕方がないが、もう少し昆虫の食べ方などのこの先の展開などの示唆があると良かった。 

おいしい昆虫記 (Natsume-sha Science) 佐伯 真二郎 https://www.amazon.co.jp/dp/4816368957/ref=cm_sw_r_tw_dp_x_tbaBFbY9ARQDY

実践 ソフトウェア アーキテクチャ

１章
アーキテクチャーは、技術やメンバーだけでなく様々なものに影響を受ける。
アーキテクチャーは少人数で作成さ、文書化されなければならない。
この章に書いてあることが全体のチェックリストになる気もするので、あとで書き下す。

２章
アーキテクチャーは利害関係者のコミュニケーション手段
初期の設計方針を決める。品質特性を決める。組織構造を決定する。再利用可能なものを抜き出すことができる。

どのようなコード単位で構造化するのか？(モジュール)
実行時の振る舞いの単位(コンポーネント)とその相互作用(コネクター)
それらをどの環境に置くか(割当)
の大きく分けて3つのビュー(見方)がある。
更に、細部には様々な要素があるがすべてをドキュメント化する必要はない。

論理ビュー
　オブジェクトやクラスなどの(モジュールビュー)
プロセスビュー
　並行性と機能の分散を扱い
配置ビュー
　ライブラリや開発の単位
物理ビュー
　プロセスや通信のノードへのマッピングを示す

How(どのように)よりはWhat(何を)するのかを明らかにすることで、議論ができるようになる。


３章
A7-E航空電子工学プロジェクトを具体例としてアーキテクチャーの構造について説明している。
分割構造は、どのようにモジュールに分割するのか？
ハードウェアを隠蔽するモジュール
ビジネスロジックを分割していくモジュール
アルゴリズムなどを格納するモジュール

使用の構造は、どの処理がどの処理を参照するのか？などだ。Layer化アーキテクチャだと改装をまたいだ参照はしないなど。

プロセス構造は
同期の順番や排他制御の場所など

航空機の具体的なものはそんなに語られていない。


第２部
アーキテクチャーと品質について。
品質はむる人によって変わる。

４章
アーキテクチャのなかで特に重要な品質特性について。
また、品質特性をどのように表現するのか。
品質特性は
刺激の発生源、刺激、環境、成果物、応答、応答測定
から表現される。



可用性を具体例とすると


可用性のシナリオ

• 刺激の発生源
• システムの内部/外部
• 刺激
• クラッシュ、障害
• 成果物
• システムの処理、メモリー、プロセッサ
• 環境
• 通教稼働している状況か、異常な状況か。
• 応答
• 記録をとる、通知をする
• 応答測定
• システムが使用可能な時間の計測、縮退状態の時間計測

変更性のシナリオ

• 刺激の発生源
• ユーザー、開発者、システム管理者
• 刺激
• 機能、品質特性に対する追加改善変更
• 成果物
• システム、UI、プラットフォーム
• 環境
• 実行時、コンパイル時、設計時の環境
• 応答
• テストし、配置する
• 応答測定
• 時間、コスト

性能のシナリオ

• 刺激の発生源
• ユーザー
• 刺激
• トランザクション、秒間X回、read, write
• 成果物
• システム
• 環境
• 通教状態/非常状態/高負荷状態
• 応答
• トランザクションが処理された結果
• 応答測定
• イベントが発生してからの応答の時間

セキュリティのシナリオ

• 刺激の発生源
• 個人/システム、権限のある/ない、
• 刺激
• データの変更の試み
• 成果物
• システム内のデータ
• 環境
• オンライン/オフライン、ファイアウォール内/外
• 応答
• アクセスを承認する/拒絶する/記録する
• 応答測定
• アクセスの記録/攻撃の検出/データの復元

テストの容易性のシナリオ

• 刺激の発生源
• テスト担当者
• 刺激
• テストの実行
• 成果物
• 設計、コード
• 環境
• 設計時、コンパイル時、Deply時
• 応答
• テスト結果
• 応答測定
• カバー率、実施時間、依存関係

使いやすさのシナリオ

• 刺激の発生源
• ユーザー
• 刺激
• ユーザーニーズ、効率的に使いたい、エラーを最小化したいなど
• 成果物
• システム
• 環境
• 実行時、設定時
• 応答
• システム学習支援/効率的な利用支援/エラーの最小化/国際化
• 応答測定
• 作業時間、エラー数など

様々な品質特性はトレードオフの関係にある。これを比較するために刺激に着目し、関連するのか独立しているのかをまとめると良い。

他にも規模拡張性、移植性などの品質特性がある。

ビジネス品質

• 市場投入までの時間
• コストと利益
• システムの寿命予測
• targeted market
• 改善投入スケジュール
• 既存システムとの統合

５章

アーキテクチャーの実現方法がテーマではあるが、やや抽象的な話に終止する。

可用性

多数決というのは、複数システムにより処理して、多数のシステムがOKならOKとかそういうこと。

変更容易性

セキュリティ

使いやすさ

性能

テスト容易性

６章

航空管制システムを例にとって説明している。

物理ビューや分割ビューなどあって実用的かも。

実現方法をすべて細かくはかけないが、これらをチェック・ポイントして見直せば良いと思う。

物理ビュー

モジュール分割ビュー

プロセスビュー

クライアント・サーバービュー

コードビュー(機能がコードのどこにmappingしているかを示す)

対障害性ビュー

各ビューはシステムの異なる視点からの記述であるため、当然同じような名刺が登場する。

アプリケーションはプロセスやクライアントサーバービューに出てくるといった具合だ。

マッピングを示すことでわかりやすくなる。

ただ、これらは完璧なセットではない。システムによって必要なビューは異なる。

そのシステムがどのような品質特性を満たそうとしているのかを記述するためにこれらはセク製される。

７章

アーキテクチャーを具体的にどのように設計していくのかのステップが記述されている。

そのまま全文のせたいくらいである。

1. 分割するモジュールを選択する
2. モジュールを詳細化する
1. アーキテクチャドライバを選択する
2. アーキテクチャパターンの選択
3. 複数のビューを用いながらモジュールをインスタンス化して、機能性を割り当てる
4. サブモジュールのインターフェースを定義する
5. ユースケースと品質シナリオをサブモジュールの制約として検証して、詳細化する

アーキテクチャドライバとはシステムの方向を決める要求のこと

８章
シュミレータについての具体例を示している。
統合容易性という大規模システムでは非常に重要なものを取り扱う。

リアルタイム処理と逐次処理の２つの統合について語られているが、具体的には以下のところくらいだ。

Timeline Synchronizerなるものが統合のメインになりそう。

9章
アーキテクチャーの文書化とは、各ステークホルダーのコミュニケーションの促進であり、システムへの理解を助けることにある。
見るステークホルダーのコミュニケーションのニーズがどこに有るのか？によって視点が変わり、書くべきことも変わる。

具体的な文書化の方法が書かれており、全体的にリスト化したいところだ。

適切なビューを選択すべきである。

• 候補となるビューをリスト化する
• ビューを組み合わせて文章を見る人のニーズを満たせるかチェックする
• 優先順位をつける

各ビューでは、

1. プライマリープレゼンテーション
2. 要素カタログ
3. コンテキスト図
4. 可変性ガイド。どのように変更できるか
5. アーキテクチャーの背景
6. 用語集
7. その他の作者や変更履歴など

を記述する。

また、インターフェースを定義しなければいけない。

どこのインターフェースということだが、システムのインターフェースになると思う。

リソースに着目し、どのリソースをコントロールするモジュールで、どのリソースを提供したり利用したりするモジュールなのかなど。

1. インターフェースの識別子(名前やID)
2. 提供するリソース
3. データ型
4. 例外の定義
5. 提供されるか編成(関数を受けれて処理を変えられるのかなど)
6. 品質特性の特徴
7. 要素の要求
8. 根拠と設計の背景
9. 使用ガイド

また、ビュー間をまたぐ文書を作成する必要もある。

ビュー同士の関係を記述することでわかりやすくなる。

1. ビューカタログやビューテンプレートを利用し
2. システムの概要とビュー間の要素のマッピングを記述し
3. なぜそれが選ばれたのかを記述していく

モデリングにはUMLなどを用いても良い。

10章

アーキテクチャーを再現する。

文書がないときに作ることに相当する。

データから分け始めて、ツールに夜よるのが良さそう。

第3部
アーキテクチャーを評価するのは計画的に行われるべきで、それが早期に行われることでシステムの問題が浮き彫りになる。
ATAM、CBAMなどの具体的手法もある。

11章
ATAMの説明と具体例について記述している。
ATAMについては、かなり具体的にきじゅつされている。
評価チーム、アーキテクト、ステークホルダーの3つの集団が評価に参加して、最終的にレポートを上げる。
評価方法のステップまで示されているので、この本に書いてあることをそのまま行えば、きちんと評価できる気はする。ただ、細かすぎるので中くらいのシステムやアーリータイミングでのシステムでは向かないかもしれない。
ただ、規模感を小さくして行うのは価値があると思う

12章
CBAMの具体的な進め方についての記述がある。
コストを考えてて、そこからアーキテクチャーを評価することになるという切り口。
品質特性とコストを場合分けして、それについて投票して決めていくというのは有効な手段であると思う。
ただ、利益を計算して費用対効果が最も良いものを選ぶとあるが、利益がかんたんに計算できることは稀だし、資料作成者の作為が入る可能性が高いと思うので、利益については考慮しないほうが良いのではないかと個人的には思う。


13章
WWWの発展を通して、アーキテクチャーの変更容易性について記述している。
具体的すぎて、逆にWWWの紹介のようになっている。
また、ちょっと規模感が大きすぎて参考にならない面もあるとおもう。


14章以降
プロダクトラインに対する考えと具体例が続く。
プロダクトラインの考え方は、市場に投入する製品群にたいして適切な共通システムを抜き出して再利用するのか？という点にある。
少々ハードウェア寄りで、現在のシステム開発とは違う気もするが視点として共通部分を抜き出すというのは考えるべきところだと思う。


全体を通して言えるのは、組込みシステムなどに向けたアーキテクチャーの例が多いという点だ。
CPUや物理の構成を理解するのは重要だが、現在はそれらも抽象化されており、ある程度雑な見積もりをしてもあとから変えられる部分が大きいので、低レイヤーの設計において、この本の書いてあることを忠実に守る必要はないと思う。
ただ、手法や考え方は現代にも通じると思うし作業リストを作る際の抜け漏れなどをチェックするにも非常に有効な本だと思う。

マイクロサービスパターン［実践的システムデザインのためのコード解説］

良い本でした。
マイクロサービスというタイトルだけどアーキテクチャーについて網羅的に記述ている。

Chap1
SOAとの違いは、データベースがサービスごとにありグローバルに参照するわけではないこと。
単純なアプリならモノリシックな方が良いことのほうが多い。


Chap2
command=データの更新系
query=データの読み出し
業務(ドメイン)に従ってサービスを分けていく


Chap3
Service間で通信は必須

同期・非同期がある。
同期ではOpenApi、gRPCが主に使われる。
Circuit breaker(失敗が続いたら受付を止める処理)は必須。
マイクロサービスのフレームワークにあったりするので探すのが良い。
サービスディスカバリーもEurekaなどライブラリーがある。
Dockerやk8sはサービスディレクトリを提供する。可能な限りこれを使うほうがメンテナンスがしやすい。

非同期ではmessage brokerがメッセージを仲介する
非同期では、リクエスト/レスポンスのスタイルと一方通行の２種類のスタイルを分けてドキュメントを作る必要がある。
Kafka/JMS/RabbitMQなどがある。
MQはat least onceなので、重複するメッセージが来る。
冪等性の確保は必須。データベースにmessage idを保存するなどして対処する
メッセージの送信の信頼性の確保にはoutboxデータベースを送信元で作成して、それをpolingするかdbのtransaction logをtailingする。
著者はEventuate tramというフレームワークで高レベルapiを用意している。

非同期にすることで可用性は上がる。


Chap4
サーガとは複数のサービスで一つの目的を達成するための単位。
コレオグラフィとオーケストレーションの２択がある。
コレオグラフィは、各ServiceがP2Pで連携するイメージ。
オーケストレーションは、Ｏ家すとれーたクラスで一括管理すつ方法。
オーケストレーションの方が、一箇所にまとまりやすいのでおすすめ。

オーケストレーションでステートマシンで管理するのがよい。
ロールバックなどの命令もここでやる。
サーガには３ステップある。
補償可能トランザクション：補償トランザクションでもとに戻すことが可能。
ピボットトランザクション：このトランザクションが成功したらあとは成功するのみの分岐点。
再試行可能トランザクション：ピボットトランザクションのあとで確実に成功するトランザクション
カウンターメジャーで、処理の順番の不整合に対処する。イベントが期待通りの順番に飛んでこないこともあるので、その場合に対処する道具がカウンターメジャー.。
pendingなどの状態で管理するsemantic lock
処理の順番が入れ替え可能にするcommunicative update
処理の不整合が発生しそうなupdateを最後に持ってくるpessimistic view
処理の最初にreadして、もう一度更新前にreadした値が更新されていないかcheckするreread value

OderServiceがOderSagaStateを作成するような形で、Sagaを作るのもまたService

Chap5
外部イベントを受け取るHandler
外部にイベントを出すPublisher adapter
データベースとやり取りするDatabase adapeter


Aggregateはそのroot同士だけでやり取りする。
主キーでお互いに参照するoderが参照するconsumerはconsumer idとなる
１つのトランザクションに対応するのは１つのaggregate


Chap6
イベントソーシング
アグリゲートを永続化するときにそのデータを保存するのではなく、イベントをすべて保存することで、あとからそのイベントをすべて処理することで、前回の状況を再構築する。
アグリゲートはprocessとapplyに分かれる。
processでイベントを複数作成し、そのをapplyでアグリゲートに適用。
イベントを保存する。
イベントを途中から再開するときは、イベントのセットを読み出してapplyを繰り返し呼び出しアグリゲートを復元。processを呼び出して新しいイベントを作って、また同じことの繰り返す。
イベントを複数処理し終わったアグリゲートを保存したスナップショットを作ることでパフォーマンスは上がる。
冪等性担保には、processed_idをtableにwriteすることで対応。
イベントソーシングでのイベントの更新には、アップキャストと言う方法を用いる。
データベースからイベントをloadするときにインスタンスを新バージョンに変えるのだ。

Chap7
CQRS
コマンドとクエリーの分離を意味する。
クエリー用のDBを作成することで、複数回のネットワークアクセスをしないようにするなどの工夫ができる。
レプリケーション遅延の問題なども起こるが、UI上の問題であればClientのDBを予め更新しておき、あとからServerと同期する形にしても良い。


Chap8
GatewayはそれぞれのFrontend向けにできるだけ分けたほうが良い。
gatewayは
認証、認可、流量制御、cahcing、メトリクスの収集、リクエストのロギングなどの役割がある。

API Gatewayも製品がある。LongやTraefikなどZuul、Spring Cloud gatewayもある。

GraphQLはスキーマ、リゾルバ、Proxyに分かれる。スキーマはI/F、リゾルバはServiceとのmapping、Proxyは実際のServiceの呼び出し。
GraphQLを使うメリットは、クライアントがqueryを打てるようになるイメージに近い。
様々なデータを様々な組み合わせでよく取得するような場合に、最も効果を発揮する。


Chap9
Serviceごとの契約(I/F)の検証としてSpring Cloud Contractなどがある。
Pactフレームワークの一種


Chap11
サービスはそれぞれ、観測可能であるべき。
Health check api
Log aggregation：複数のログをまとめ上げて、開発者が見られる形にする。log4Jとか。Elasticsearchとか、LogstashとかKibanaとか。
Distributed tracking:リクエストに紐づくIDを与えて各サービスでも追いかけられるようにする。分散トレーシング、Zipkinとか
Exception tracking：例外をcacheして開発者にアラートを送る。HoneyBadgerとかServlet Filterとか
Application metrics：カウンターやゲージなど
Audit loggging:ユーザーの行動を計測する。Spring AOPとか。

Microservice chassis(マイクロサービスシャシー)、必要なものが一通り揃ったやる。
Spring Cloud、Spring Bootとか。


Chap12
デプロイは、まあDockerだろうな。
Istioが最もポピュラーなサービスメッシュ
k8sつかって、Envoyをサイドカーとしてデプロイする。
いろいろ変わりそうなところではある。

Chap13
モノリスのリファクタリングについて。
まずは、モノリスのGatewayに相当する部分を抜き出してみる。
新規機能追加のときにServiceとして作ってみる。
必要なデータは、レプリケーションなどしてコピーしたりもする。
マイクロサービス化していったときに、モノリスをロールバックするのは不可能と言って良い。
なので、モノリスは最後の最後に、処理が終わったら必ず成功まで行くという後半に持ってこないといけない。








https://www.amazon.co.jp/dp/B086JJNDKS/ref=cm_sw_r_tw_dp_U_x_e8q0Eb9X2E665

Javaによる関数型プログラミング

内容は悪くないけどKotlinで良いのでは？という気もする。
Streamの説明に多くのボリュームが割かれているが、遅延評価やストリームがそこまで必須になることも少ないと思う。

ただ、
http://media.pragprog.com/titles/vsjava8/code/lazy/fpij/Holder.java
一応backup
これは、非常に面白い。
インスタン生成の遅延をthread safeに行っている。


Javaによる関数型プログラミング ―Java 8ラムダ式とStream   Venkat Subramaniam https://www.amazon.co.jp/dp/4873117046/ref=cm_sw_r_tw_dp_U_x_Y0ZJEbMJA8738

ビットコインはチグリス川を漂う――マネーテクノロジーの未来史

ビットコインの本ではなく、マネー自体の未来を考えている本。

マネーとは
計算単位であり、貯蔵手段であり、交換媒介物であり、支払い繰延手段である。

Bank4.0での第一原理と近い。

お金が今の形になったのは、ここ１００年くらいで、実は歴史は浅いので、変わる可能性は大いにある。

中央政府が発行する通貨発行益を手放さない可能性もある。
また、マネーに匿名性が必要とされるかも？しかし、匿名性はあまり重要ではなさそう。
現金を使うのは、貧困層だけになるだろう。

電子化、キャッシュレス化が進む中で、ビットコインのような特性のものが必要とされるだろうということが論じられている。


ビットコインはチグリス川を漂う――マネーテクノロジーの未来史   デイヴィッド・バーチ https://www.amazon.co.jp/dp/4622086948/ref=cm_sw_r_tw_dp_U_x_oLiJEbDH9YKA4

アントフィナンシャル――1匹のアリがつくる新金融エコシステム

アントフィナンシャルの成り立ちについて書いてる。
いまでいうFinTechの走りだが、彼らはTeckFinであり、あくまで技術を提供する会社という意識らしい。

もともと、金融業で儲けようというよりは、アリババで決済に課題があり、それを解決するためのアント・フィナンシャルだった。
決済をスムーズに行うための信用が鍵になっていた。信用をアントフィナンシャルが保証することでアリババでの決済をスムーズなものにした。

ニーズから自然と生まれたという印象で、現在のFinTechとは少々印象が違う。

取引の信用問題の解決から、小口事業屋への融資などがスタートしている。
それらもやはりニーズありきだ。
QRコード決済もクレジットカードが無いから生まれた面もある。

もともと信用情報を提供することで市場での取引をスムーズにした面があるので、信用スコアなども自然と浸透したのだと思う。

現在の日本の状況等はだいぶ違う。

アリペイなどとの競争を見るとニーズからスタートしたのではないようにも思えるが、完全にユーザーニーズを満たすために生まれたのであり、だからこそ広まったのだなと思わせる。

やはり第一原理を考えるという基本的な姿勢が重要だと教えてくれる。良い本。

アントフィナンシャル――1匹のアリがつくる新金融エコシステム   廉 薇 https://www.amazon.co.jp/dp/4622087758/ref=cm_sw_r_tw_dp_U_x_RchJEbVWSJGSA

BANK 4.0

未来の銀行がどの様になるかを論じている。
どのような業界も第一原理があり、それを満たす。更新する。より良い状態にすることで世の中を席巻できる。
バンキングの第一原理とは

• 貯蔵価値：貨幣を安全に貯蔵する能力(投資含む)
• 資金移動：お金を安全に動かす能力
• 信用アクセス：必要時にお金を貸す能力

1. お金を安全に預かってもらいたい
2. お金を迅速に贈りたい
3. 将来のために夢のために目的のためにお金をためたい
4. 雇用者への賃金の支払いをしてもらいたい
5. 必要なものを買うお金をもっていないので短期融資がほしい
6. 社員に給与を払いたい
7. 家を買いたい
8. 請求書の支払いをしたい
9. 外国にいるときの支払いをしたい

などの欲求を満たすことが大事

規制当局はKYCに頭を悩ませるだろう。IDの概念が変わる可能性がある。

など、前半が非常に面白い。
後半はIoTとか自動化とかAIとか著者の妄想も結構はいっているので、前半の規制当局のところまでで読むのは良いかもしれない。

信用アクセスは、AMLや規制当局との関係があるが、どちらにせよマネーが変わるよ言うことは、IDのありようが変わる可能性を示唆している。という点で一読の価値のある本だった。

BANK4.0 未来の銀行   ブレット キング https://www.amazon.co.jp/dp/4492654860/ref=cm_sw_r_tw_dp_U_x_FbeJEbHS6E9F2

カンバン仕事術

ストーリー仕立てになっていて、わかりやすいです。

チームの運営がうまく行っていない時に、立て直しの手段として使うのに良さそう。
ただ、人間関係まで壊れていないチームに限るとおもう。
お互いに嫌い合っているような場合には、そもそも何をやっても無駄だけど、このような手法も使えないと思う。

紙で行うことで、整理されるし、一体感も多少は出るのでやるのはあり。
ただ、大抵の場合はチームの運営がうまく回り始めると紙ではなくJiraなどで管理したほうが効率的だったりする。
スタートアップやそれと同等規模の人数のプロジェクトに限って提供すべきかなと思う。

また、チームの誰かがファシリテーターをやるのではなく、外部からファシリテーターを頼むのが良いと思う。ファシリテーションしながら計画も立てながらというのは、かなりなれていても難しいと思う。

カンバン仕事術   Marcus Hammarberg https://www.amazon.co.jp/dp/487311764X/ref=cm_sw_r_tw_dp_U_x_KycJEb1MMT9SY

Deep Learning Javaプログラミング 深層学習の理論と実装

悪い本ではないと思うけど、そんなに刺さる内容の書いてある本でもなかった。
Deep learingをこれから本格的に自分で実装しようという学生向けという感じ。
ある程度知っている人や、中身の研究をしたいわけではなくて応用がしたいだけの人にとってはどちらも物足りない内容となっている。

最後の方の著者の意見については面白い部分がある。
ディープラーニングでも層の設計やパラメーターのチューニングが必要で、魔法ではない。
現実の問題を解く際にはディープラーニングを利用するよりもベイズ、協調フィルタリング、サポートベクターマシンなどの既存の手法を用いるほうが良い結果がでる。
など、実際に、機械学習に実務で取り組んだことがあるのだなと感じる率直な意見だと思う。


Deep Learning Javaプログラミング 深層学習の理論と実装 (impress top gear)   巣籠悠輔 https://www.amazon.co.jp/dp/4844381288/ref=cm_sw_r_tw_dp_U_x_CfcJEbXA4NAVW

――システム構築の大前提―― ITアーキテクチャのセオリー

アーキテクチャの構築の実践の可能性があるなら一読する価値があるきがする。
本自体がうすいので、内容もそれほど濃くはないが、話は全体的に具体的なのがよい。

アーキテクチャをDA,AA,TA,とわけて考えて、それぞれの目指すべき成果物の例があるのも良い。
マスターデータHUBや、TransactionデータHUBの考え方は、サービスを疎結合にするのに役に立つと思う。

ただ、HUBが完全に単一障害点になるので、HUBを作ったとしても可能な限り参照系を増やすなど工夫はいると思う。

なんにせよ良い本だし。

TransactionデータHUBなどは、Transaction Resourceなどと同じような考えかなとか思うが、具体的な実装が書かれているわけではないのが残念。
そのへんを具体的にしてもう少し厚くして本を出してほしい。

https://www.amazon.co.jp/dp/4865941169/ref=cm_sw_r_tw_dp_U_x_Aw1GEb9CD1PQP

進化的アーキテクチャ

アーキテクチャ設計の具体的なものは4章にすこしあるが、内容としてはDepOpsの観点からみたアーキテクチャについての本だと思う。
データのアーキテクチャについては、もう少し紙面を割いて丁寧に説明してくれても良いと思う。データの陳腐化とその更新が課題になることが多いと思うので。

しっかり読む本というよりは、実際にアーキテクチャを組んだあとに一息ついて、6.5章を見直して、できてない部分があるかをチェックするのに使う感じだと思う。

他に似たようなことが書いてある本があればいらないかも。

https://www.amazon.co.jp/dp/4873118565/ref=cm_sw_r_tw_dp_U_x_Sf1GEb2SW5ECM

世界は分けてもわからない

評判が良かったので読んでみたが、面白くはなかった。

最初は、細胞などについて連続して分けることはできない、科学的なものの見方について論じていくのかと思ったが、最後の方はATPについての実験の不正の記述に終止しており、それがどう分けてもわからないのかわからなかった。
内容がないといえばそれまでである。

China 2049

アメリカの中国に対する見方や評価について、いかに誤解があり間違っていたのかをひたすらに語り続ける本。

具体的な数字などはないが、定性的な評価は納得感があるし、現実の中国の行動を明らかにしてもいると思う。

中国という国家に対する見方も変わる。

特に、中国内部において、戦国時代の戦略等をきちんと分析して活かそうとしている。また、その期間が西洋的な観点から見ると異常に長いということだ。

それを本書ではマラソンと読んで100年の計画としている。

実施問題、中国の本というのを読める人はほぼいないし、翻訳された本が市場に出回ってもいないので、中国の常識や思想みたいなものを理解してる人は西洋文明にはいないように感じる。

勝手に西洋的な常識で動いているのだろうと勘違いしては行けないと教えてくれる。

詳細がわからないまでも、そういった西洋の常識とは違う常識で動いている国家がいるよ言うことが示されているという点で読む価値はあると思う。

また近代の中国はロシアや日本の失敗から学んで、経済的にも成功を収めているというのは非常に面白い。

ロシアの国営企業を二束三文で売り払って、一部の金持ちを生むようなこともしていない。

未だにたくさんの企業が国営で、ファーウェイもそうだという事は気に留めて置かなければならないと思う。

時間は存在しない

面白くはあるが、科学的な記述を期待した人はがっかりするかも。
殆どが詩的な表現で科学的とは言えない。もしくは翻訳が難しいのかも。

時間も連続的だと思っているが、離散的な値をとり電子などのように最小単位があるという考えや関係性を記述する最新の方程式にはtがないとかは面白かったが、そこがピークで、あとは詩的な記述で少々たいくつであった。

https://www.amazon.co.jp/dp/4140817909/ref=cm_sw_r_tw_dp_U_x_9IfnEb1EFNXNF

バッタを倒しにアフリカへ

博士課程に進むことがいかにリスキーかを教えてくれる。
著者は楽しいと思うし、こういう生き方があるというのを広められるのは素晴らしいともう。
子供に選択の幅があることを伝える本であると思う。
それと同時に本気で博士を目指すなら、この本にあるような異常な苦労が待ち受けていることをきちんと高校生くらいになったら知るべきかなと思う。

これだけの活動をして、おそらく博士の中ではエリートに属すると思うが、それでも40近くても任期付きの職にいるのであるから大学の世界は非常に厳しいと感じる

バッタを倒しにアフリカへ (光文社新書)   前野ウルド浩太郎 https://www.amazon.co.jp/dp/4334039898/ref=cm_sw_r_tw_dp_U_x_CsBmEbNRTFSHS

平成金融史

平成のバブルの発生から現代までを追ったドキュメント。
バブルといえば、派手なイメージしかないし、景気の過熱と思っていたけど、長期的に低金利で、高金利はバブルがはじけ始めてからというのがわかる。
金利を上げたいけど、物価上昇がないから金利を上げられない日銀が招いたことと言われても仕方がない気もする。将来を全員が予想できると思う始めると過剰にリスクを取り始めて、それがバブルにつながるということだ。
現在も、低金利が続いていて株価が上がりつつあるので、当時と近しい部分もあると思う。当時と違うのは株価の上昇のそれなりの割合が、日銀による買オペの結果だということだろうか。

自分のように８０年代生まれだと、この本に書いてあることを子供のころから実際に見ているので、非常に面白い。
「中央銀行」を読んだ際にはみんな官僚なども含めてバブルに誠実に向き合ったような印象を受けたが、実際には自分の任期中にはトラブルを起こしたくない官僚や大きすぎて潰せないと思い込んで、もはや退場すべき会社を生き永らえさせているような政策をとってしまう日銀や政府といった面も見えてくる。
退場すべき会社の下支えは現在も行われているように思える。日銀の買いオペは、その例といえると思う。

今では考えられないが、昔は都市銀行が21行もあり、それが統廃合を進めた結果3つになったのだから驚きだ。

不良債権処理計画も当初から10年単位の計画が組まれており、失われた10年などというが、失われるのが計画された10年といえる気もする。

当たり前ではあるが、現代へとこれらの状況が地続きであるから、現状の日銀の資産や打ち手の出口の見えなさなどに不安を覚える。


https://www.amazon.co.jp/%E5%B9%B3%E6%88%90%E9%87%91%E8%9E%8D%E5%8F%B2-%E3%83%90%E3%83%96%E3%83%AB%E5%B4%A9%E5%A3%8A%E3%81%8B%E3%82%89%E3%82%A2%E3%83%99%E3%83%8E%E3%83%9F%E3%82%AF%E3%82%B9%E3%81%BE%E3%81%A7-%E4%B8%AD%E5%85%AC%E6%96%B0%E6%9B%B8-2541-%E8%A5%BF%E9%87%8E-%E6%99%BA%E5%BD%A6/dp/4121025415

イスラム教の論理

著者の飯山 陽は、他のイスラム教の研究者からは批判されることもあるようだが、本書は明らかに良書。
西洋の価値観と違った価値観の世界があることを記述している。
社会主義国家に対しても言えることではあるけど、西側の視点でだけ世界を見るのではなく、いろんな視点が存在するという事実を認識するのは大事だと思う。
内容的には、イスラム過激派がコーランをどのように解釈しているのかを繰り返し述べている。
ちょっと内容的には、繰り返しが多い気もするが、それだけテロを正当化する論理にバリエーションがあるということなのだろう。
イスラム教の論理ではジハードを根拠としたテロ行為を論理的に否定することは難しいという現実があることは分かった。

他のイスラム教の研究者から嫌われるというのもちょっとわかる気がする。
日本人が感じるイスラム教への違和感などについて、正面から一つの回答を出そうとしているだから、それが出来ていない研究者からしたら目障りにはなると思う。
学者としては、回答がない疑問への答えを見つけようとする試みは、褒められるべきだが、そういった評価ではないというのは、日本のイスラム教の研究者社会は学術的価値をあまり生み出していないのかも等と邪推してしまう。

https://www.amazon.co.jp/dp/410610752X/ref=cm_sw_r_tw_dp_U_x_70YhEb5AM6FFJ

良いコードを書く技術

表紙や中身の漫画から内容が薄いかなと想像したが、思ったよりも良書。
普通に名前付けの章とか参考になる。

ライブラリ/フレームワーク
*Scope, *Loader, *Engine, *Provider, *Conversion, *Behavior, *Descriptor, *Cache, *Resolver, *Processor

GUI/フレームワークを拡張する部品
*Listener, *Hander, *Runner, *Command, *Observer, *Node, *Adapter, *Proxy, *Holder, *Context, *Monitor, *State, *Builder, *Factory, *Visitor, *Decorator, *Strategy

アプリケーション
*Action, *Controller, *Dto, *Logic, *Service, *Util, *Entity, *Helper, *Support, *Dao, *Manager, *Bean, *Form, *Exception, *Validator, *Test, *Impl

一部、使わないほうが良いものもあるきもするけど。。

https://www.amazon.co.jp/dp/B07JHP988R/ref=cm_sw_r_tw_dp_U_x_QAjhEbS2N82KZ

中央銀行

これ、かなり面白かったです。

僕と同年代の人なら概ね面白く読めるのではないかと思います。
35歳前後。

学生時代とか社会人なりたての頃にテレビで行われていた経済についての議論の中心にいた日本銀行の総裁の書いたもので、当時感じていた違和感に対する日本銀行の中の人が何を感じていたかがわかって面白い。

当時は、日銀の施策で景気が回復するのだから、日銀がなんとかすべきみたいな論調があったと思うが、金利をいじったりお金の供給量を増やすことで本当に景気が回復するのだろうかという違和感を個人的には感じていた。
韓国企業などには、すでに製造業は負けていたし、海外ではまるでシェアを取れていないことは明らかだった。

実際に日銀の人たちも、金利の操作などで景気が回復するとは思っておらず、景気が悪い原因は生産年齢人口の減少にあるというのは調査から明らかだったようだ。
当時から少子化とは言われていはいたが、経済に深刻なダメージを与えるといった論調は聞かれなかった気がする。しかし、日銀などの内部で明らかだったようでレポートなども作成されている。
https://www.boj.or.jp/research/brp/ron_2012/data/ron120831a.pdf

生産年齢人口の変化は１０章などでも取り上げられており、参考になる。

日銀自体が、巨大なシンクタンクで、レポートも出しているので、今後も追いかけるべきだと思うには十分な説得力を持つ本になっていた。
他のレポートは
https://www.boj.or.jp/research/brp/ron_2019/index.htm/
このあたりにある。

日本の景気に対する見方もちょっと変わったと感じている。
日本人の能力の変化というよりは、不良債券が多すぎたために、企業が新規の投資をすることが出来なくなり、人も雇えなくなり、古いものを古い人達が古いやり方で継続する以外に選択肢がなかった。
その間に、アメリカなどではIT企業が育ち、もはや勝ち目がないくらいに差が開いてしまったといった感じだ。
人も技術も古くなっても終身雇用で人を変えることもままならないというのは、不良債権に限らず、経済的な問題が社会全体で発生した時に、取り戻すのに時間がかかる要因になっているのだなと感じるなどする。

日本型の終身雇用でうまくいくためには、継続的な新卒採用とセットであるが、それも止まった期間があるので、知識や文化の継承もままならず、取り戻すのにあと２０年くらいかかるのではないかと危惧する。


https://www.amazon.co.jp/dp/4492654852/ref=cm_sw_r_tw_dp_U_x_EAihEbY7QR38B