良い戦略 悪い戦略

 良い本だと思う。

戦略と目標は違うと教えてくれる。

戦略には条件がある。

• 診断
• 状況を診断し、取り組むべき課題を見極める。良い診断は死活的に重要な問題点を選り分け、複雑に絡み合った状況を明快に解きほぐす
• 基本方針
• 診断で見つかった課題にどう取り組むのか、大きな方向性と総合的な方針を占めす
• 行動
• 基本方針を実行するために設計された一貫性のある一連の行動のこと。すべての行動をコーディネートして方針を実行する

戦略には具体的な行動に結びつくものでなければならないし、それがないと空虚なスローガンに終わる。

これらが含まれているかを意識しつつ、最初に思いついた頃を破棄してみるのも一つのテクニックとなる。

また何か規制が変わるとき、ルールが変わるときにはチャンスが生まれるとも言っている。

日本の思想

 文章がとっつきにくい。また、あとがきを読めばわかるが、日本の思想について書き下ろされたものではなく、雑誌に掲載された４つのテーマについてまとめたものとなっている。なので、日本の思想についての内容だけなら１章だけ読めばよい。自分は３，４章はあまり読む気になれなかった。内容が唐突に感じた。事前知識が必要すぎるのかもしれない。

日本の思想については面白い内容とは言える。

日本には、歴史的な思想の積み上げがないが、とはいえ過去からの影響もあるので、どのような影響を受けつつ、これからどうやって積み上げをしていくのか？

というテーマについて書かれている。外国からの思想を統合するというよりは、雑多に並べただけの状態から伝統を作って国をまとめるために国体という概念が導入されたが、國體自体が雑多なものだったので共通認識もないまま、雑多なまま現代にいたっている。専門分野同士もつながらずタコツボ化が起こっている。

タコツボ化は、まあしょうがないとしても、それれを統合した積み上げのある思想のようなものが日本に無いのは今も変わらないと思うし、積み上げ方も特に示されてはいない。

指摘したこと自体に価値があるのだろう。

日本の場合は、積み上げがないので論争がいつまでたっても似たようなことの繰り返しになるのであるとしている。

しかし、アメリカなども似たようなものではないかと思う。

達人プログラマー

 良い本です。

当たり前のことが書いてあるわけですが、当たり前のことをきちんとやっていくのが難しいというのを思い出させてくれます。

普段、自分が当たり前にやっていることもありますが、反省を促される部分もあるので、定期的にTipsなどを読み返したほうが良いかなと思いました。

自動化、コードジェネレータ、契約的プログラム、リファクタリング、コードコメント

は意識していきたい。

Tipsはどれもつねに見直しておきたい内容であるが、７０もあるのでここでは書かない。

ソフトウェアアーキテクチャドキュメント

ソフトウェアアーキテクチャの文書化についての本。
その具体的な方法が記述されている。
テンプレもあるので、それを活用していきたい。

序章
7つのルールを守らねばならない。

1. 読み手の視点で書く
2. 不必要な繰り返しはしない。混乱の元
3. 曖昧さを避ける。独自のUML的なものを書いてもよいが処理なのかデータの流れ7日曖昧なものは避ける
4. 標準的な構成を採用する
5. 根拠を記載する
6. できるだけ最新を保つ
7. 目的に合致しているかレビューする

1部序文

ここにビューの種類がいくつかとそれを記述するときのテンプレートが記述されている。

迷ったらここに戻って見直すのはありだと思う

1章

モジュールビュータイプ

他のビューのもととなることが多い。

C&Cビューに利用されたり、組織分割と紐付いたりする。

サブシステムごとの依存関係やなにの一部であるのかなどを記述する。

2章

モジュールビュータイプのスタイルについて。

3つのスタイルについて記述している。

・分解スタイル

大体の人が分解スタイルから始める。

一部を外部調達するのか。プロダクトラインをどうこうせいするのか？プロダクトラインを作るのであるならばだが。

分解の目的は、管理可能な粒度まで分割して管理するためである。

そのため、分解は繰り返し行われる。

C&Cビューと紐付けを行うことが望ましい。

・使用スタイル

どのモジュールがどのモジュールを使用しているのか。依存しているのかを明らかにする。

依存関係が明らかならば、どこでMockを作ればよいかとか計画などが立てやすくなる。

また、テストのときの影響についても検証可能になる。

・汎化スタイル

かなり実装に近づいている。

とはいえ、汎化した上で具体的な実装がチームごとに分かれるくらいに巨大なシステムであれば有効である。

汎化によるサブシステムの差し替えとか。

・レイヤースタイル

レイヤーは縦に並べることもあれば、円になることもある。

レイヤードアーキテクチャーやヘキサゴナルアーキテクチャなどである。

移植可能性や再利用性について記述する際に必要になる。

ライブラリーなどでは必須だと思われる。

3章
コンポーネント-コネクタービュータイプ

正直、この章だけ読んでもC&Cについては、あまり良くはわからない。
重要なのは、C&Cの表現を利用することで、データの記憶、複製、通信プロトコル、並行性、変更可能性。これらを明らかにすることだ。
プロセスや通信方法やデータの保存を表現するので、実装に近づいた感じはする。

また、モジュールビューはコードなどに依存するのに対して、C&Cはプロセスや処理に依存するので、Configなどは表現されない気がする。
ただ、データが入るのでなんとも言えない。

4章
・パイプ-フィルタースタイル
重い処理などをフィルターするような信号処理などに利用される。

・共有データスタイル
データの提供元を外部から隠蔽する際に利用する。
GatewayがRepositoryにアクセスするなどのパターンがある。
その際にRPCなのかSQLを実行するのかなどを明確にする必要がある。

・Pub/Sub
Sub側がどの変更されても問題ないように作れるのが利点。
一方で、適切な表現がUMLにない気もする。

・クライアント-サーバー
クライアントが利用するサービスを切り離すことが目的となり、同時接続数などの制限が追加されたりする。

・通信プロセススタイル
並行して動作できるシステムや、コンポーネントのどれを束べて実行単位とするのかを記述する。


UMLでC&Cを表現するにあたっては、凡例が重要となる。
決まった書き方がないので、きちんと定義しないと後々の混乱が大きくなる。
コンポーネントは、モジュールビューの場合はコードと対応するが、C&Cの場合はプロセスなどと対応する。同じものが別の側面を持つ。


5章

割り付けタイプは、３つのスタイルがある。

・配置スタイル

物理的にどこにあるのか。どこで保存されるのか実行されるのかの観点で書く。

性能やセキュリティの観点で書くことになる。

・実装スタイル

ファイルのディレクトリの構成などを記述することになる。

システムのバージョンごとに作られる

・作業割当スタイル

買ってくる製品であっても担当者は置くべき。

表でセグメント、サブシステム、担当部門のような形で書けばよい。

６章

Top level context diagramを書くのはプロジェクト全体を俯瞰するのには良い。

作成するシステムとそれ以外のように分けて、相互にやり取りする情報を記述する

結合ビューは、複数のビューの関係性を記述する。

たとえば、モジュールビューとプロセスビューのような形。

　

7章

Interface設計書の構成

１．インターフェースの独自性。名前をつけバージョンをつける

２．提供されるリソースを明らかにする

     ２−１．引数とデータタイプ

     ２−２．リソースの意味。データの取りうる値。サイドエフェクト。外部から見た変化

    ２−３．制限。リソースにアクセス可能な数など

３．データタイプ。

４．エラー処理。エラー条件。

５．可変性

６．インターフェースの品質特性

７．要素の要求。呼び出しの前提条件など

８．設計の根拠と設計上の課題。背景や妥協した点など

９．ユーザーガイド。

8章

振る舞いの表し方。

・トレース。文章による書き下し。どのような刺激の結果として、どのような応答があるのかを記述する。

・ユースケースマップ。システムのin/outを記述する。また、リソースがどの処理で消費されるかを記述する。複数のケースを同時に記述可能なので、デットロックなどを見つけやすい

・シーケンス図。シーケンスは、時間に注目したものとなる。平行性などは記述しにくい。また、時間に注目するので一つのシナリオしか記述するのが難しい。

・コラボレーションズ。要素間の相互作用について記述する。シーケンスと同じようなことが書かれるが、要素間の関係性が俯瞰で見られる。

・メッセージシーケンス。あまり使わなさそう。

・静的モデル。ステートチャートは状態を表し、入れ子構造を持つ。システムが取りうるすべての状態を網羅的に記述できる。

ユースケースマップは、実験的なものだがサンプルなどはある。

振る舞いを表すサンプルなどは比較的世の中に豊富にある。

9章

アーキテクチャ文書は、すべてのViewについて書いていたらきりがない。

各ステークホルダとそれらの人の関心事の星取表を作る必要がある。

その上で、同じにできるものはあるかを検証し、数を減らす。そのうえで優先順位をつけていく。

10章

設計書のパッケージの作成について。

各Viewについては、こういったテンプレートがあるので利用すべき

文書全体については以下のような構成になる。

これが全体で、各ビューについてを２のところに書いていけば良いと思う。

設計書のレビューが必要だが、最初にプロセスについて説明したあとで、小さいグループでレビューを勧めたほうが意見が出やすい。また、設計者がレビューアに積極的に質問することで有意義なレビューにできる。

また、設計書とは別にプレゼン資料も作るべき。

1時間で50枚程度で以下のような構成

11章

UMLなどについて、どのようが表現方法があるのかが示されている。

反日種族主義

 面白い本だった。

物質主義とシャーマニズムからくる、種族を団結させるためには嘘も許容されるという韓国文化が、歴史的に敵対視している日本に向いたときに近代の反日的行動に結びついているという内容だった。

従軍慰安婦がうそであったという内容のみで話題になったけど、韓国の歴史と近代の関係について学問的調査を裏付けとした内容で読み応えがある。

慰安婦なども日本だだけでなく他にも似たような事例はあるが、日本だけを特別視して問題化しているのは種族主義ゆえよのうだ。

しかし、慰安婦は日本だけでなく、世界のすべての軍隊でいるのは当然で、理由は性病の管理と情報漏えいの防止にあったというのは、そう言われれば、世界中の軍隊にいて当然だよなと思う。当然であるから終戦直後は問題にならなかったようだ。

イラストでわかる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