図解即戦力 ビッグデータ分析のシステムと開発がこれ1冊でしっかりわかる教科書

満足度 : ★★ 読了時間 : 3.0時間

感想

ビッグデータを知るつもりで読みました。 広く浅く知るにはちょうど良いと思います｡

図解即戦力　ビッグデータ分析のシステムと開発がこれ1冊でしっかりわかる教科書

実践 パケット解析 第3版 ―Wiresharkを使ったトラブルシューティング

満足度 : ★★★★★ 読了時間 : 9.5時間

感想

パケット解析を知るつもりで読んだが､ネットワークのトラブルシューティングの知恵が盛りだくさんで非常に役に立った｡ TCP/IPの仕組みがかなりわかりやすい｡初学者でもわかる例え話を交えて説明しています｡ パケットの図解が多く､本だけでもパケット解析の方法を追体験できます｡ Cain & Abelを使うところがあったが､現在はサイトが閉鎖されていると思う｡

実践 パケット解析 第3版 ―Wiresharkを使ったトラブルシューティング

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

満足度 : ★★★
読了時間 : 2.5時間

感想

付録A､Bのチェックリストなどが本書の内容をまとめて書いており便利です｡ 図解が少ないのでイメージするのに時間がかかるかも｡ 逆コンウェイの法則などの聞き慣れない用語は巻末の用語集に説明が書いてます｡

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

ホストレベルの監視､ロギング

監視､ロギングを完備させ､ディスク障害､ネットワーク障害､CPU使用率の高止まりなどが発生したときに､ホストの問題を簡単に診断､緩和､解決できようにします｡

ロードバランサ

AWS Elastic Load Balancer､Netflix Eureka､HAProxy､nginx

カナリアフェーズ

デプロイパイプラインの第2フェーズで､本番トラフィックのごくわずかな割合(全体の2%から5%)を処理するサーバから構成される｡ステージングフェーズを通過したがまだすべての本番フェーズのサーバに展開されていない新しいビルドをテストするために使われる｡

逆コンウェイの法則

コンウェイの法則の逆で､企業の組織構造は､製品のアーキテクチャによって決まるという考え方｡

モノリス

アプリケーションのためのコードと機能をすべて含む1つのアプリケーションとしてメンテナンス､実行､デプロイされる大規模で複雑なソフトウェアシステム｡

通信､アプリケーションプラットフォームでよく見られる障害のシナリオ

• ネットワーク障害
• DNS障害
• RPC障害
• リクエスト､レスポンスの不適切な処理
• メッセージングシステムの障害
• サービス検出とサービスレジストリの障害
• 不適切な負荷分散
• 開発ツールや開発環境の障害
• テスト､パッケージング､ビルド､リリースパイプラインの障害
• マイクロサービスレベルのロギングの障害､ギャップ
• マイクロサービスレベルの監視の障害､ギャップ

ロギングしてはいけないもの

顧客名､社会保障番号､その他のプライバシー情報といった個人を特定できる情報を含んでいてはいけない｡

改訂2版 ネットワークエンジニアの教科書

満足度 : ★★★
読了時間 : 2.0時間

感想

トラブルシューティングのフローが参考になります｡ 個人的に無線ネットワークやユニファイド・コミュニケーションはネットワークエンジニアとして一般的な内容なのかわからない｡

改訂2版 ネットワークエンジニアの教科書

状況的な観点

どのような状況で発生しているのかを把握することは重要です｡以下のような点を正確に把握する｡

• その問題によりどのような影響が発生しているか(影響しているユーザ数､機器数､拠点数､サービスなど)
• いつから発生しているのか
• いつから稼働していたのか
• その問題が発生する前になにか変更した点はないか
• 現在も継続して発生しているのか､復旧済みなのか
• 復旧済みの場合はどのように復旧したのか
• ずっと発生する問題なのか､間欠的に発生する問題なのか

アレニウスの法則

使用環境の温度が10℃下がると寿命は2倍に伸びる｡

エンジニアのキャリアはT字に身に着けていく

自身と興味のある専門分野は深堀りしつつ､ほかの技術のトレンドも横に展開して時代遅れにならないように水平展開していく｡

技術者のためのテクニカルライティング入門講座

満足度 : ★★★
読了時間 : 3.5時間

感想

ロジカルに書く方法が簡潔に書いてあります。
添削前と後の例文や問題もあるので新入社員の教育に適してます。

技術者のためのテクニカルライティング入門講座

議事録は決定事項と未決事項を整理して書く

議事録は記録を残すことが目的ではありません。
会議で議論し、決定したことを関係者で共有することが目的です。また未決事項を次の会議で議論できるように準備することが求められます。
したがって、決定事項と未決事項を整理して、それぞれが何をすべきかがわかるように書く。

簡潔に書くことは情報量を減らすという意味ではない

｢これは知っているはず｣、｢これでわかるだろう｣と自分視点で書くのは危険です。 省いては行けない情報が何かを意識して、しっかり盛り込みます。

最も重要な内容を先に書く

起承転結はNG。文章を最後まで読まないと伝えたいことがわからない。忙しい読み手に負担をかけることになります。

｢など｣を多用しない

日本語の文章によく使われる｢など｣ですが、英文では｢など｣を複数の例示の最後につけるような表現は使いません。 英訳するときに、誤訳につながる危険性があるから使わない。

ポジティブフィードバックと修正点をコメントする

よくかけている箇所にポジティブフィードバックを入れること、修正したほうが良い箇所に指摘を入れる。

日程や期限を明記する

日程や期限は、次の仕事に関わる重要な情報です。 ｢返信をお願いします｣だけでなく、いつまでに返信してほしいか、日付と時間を書きましょう。

情熱プログラマー ソフトウェア開発者の幸せな生き方

満足度 : ★★★★★
読了時間 : 3.5時間

感想

あるブログでおすすめされていたので読んでみました。
この本はよりよい人生を送るための方法が色々と書いてあります。
プログラマーじゃなくてもエンジニアじゃなくても人として役立つ知恵が満載でした。

情熱プログラマー ソフトウェア開発者の幸せな生き方

君の周りにいる人たちが君自身のパフォーマンスに影響する

人はどんな仲間と一緒にやるかで腕をあげたり落とすこともある。
他人のせいばかりにしてはいけないと前置きします。
しかし、周囲の環境は影響力が大きいです。 例えば、健康な人でも公害が発生している地域に住んでいれば、体を蝕みます。

自分で勉強し始めよう

老子の教えで｢魚そのものを頼めば、それは一日の糧となる。魚の釣り方を教えてくれと頼めば、それは一生の糧となる｣
さらに、教えてくれと頼むだけじゃなく、自分で勉強をしよう。

パーキンソンの法則

｢与えられた仕事をするのにいくらあっても余ることはない。｣

良いマネージャの役割

チーム全員の仕事を把握しておいて難しい局面で手伝うのは良いマネージャの役割ではなはい。
良いマネージャの役割は、チームの仕事に優先順位を設定し、チームが仕事をこなすために必要なものを用意し、チームがやる気生産性を維持できるように配慮し、最終的に要求を実現することにある。

野心を抱け。でも前目に出すな

マネージャとして、最も扱いに困る存在は常に昇進のことを考えている従業員だ。 こういう人物の悲しいところは、次の段階を念頭においているので、現在の職務では月並みな仕事しかしないことだ。

上記の文を本で読んで、昔の自分が当てはまり頭が痛かった。
未来は今の積み重ねで出来上がる。今が小さいと未来も小さくなるということを気づいてなかったことを思い出す。 この間違いは赤とんぼででてくる立川談志の言葉で気付かされた。

現実は事実だ。そして現状を理解、分析してみろ。そこにはきっと、何故そうなったかという原因があるんだ。

赤めだか (扶桑社ＢＯＯＫＳ文庫)

ミスにどう対処するかでお互いを判断する

僕らはみんなミスを犯す。道理をわきまえた人なら、犯したミスで他人を判断しない。
発生するミスにどう対処するかでお互いを判断する。

UNIXという考え方―その設計思想と哲学

満足度 : ★★★★
付箋数 : 9
読了時間 : 3.5時間

 

■感想

漠然とLinuxを使っていて、なんでWindowsとかもあるのにUnix/Linuxなのか気になったので読んでみました。

なぜUnix/Linuxを使う理由が本の中に記載されている 考え方から紐解かれていきました。

 

■メモ

90%の解を目指す。100%よりも90%のほうが能率的で費用対効果が高い。

 

Unixはすべての詳細な設計を作らずに試作から進化して設計の手直しを繰り返して成長してきたという話は、総力を挙げて成長する方法のブリッツスケーリングと似てると感じた。

 

効率より移植性を重視する。

効率を選択すれば移植性に劣るコードができ、移植性を選択すればときに効率がいまいちになる。

 

梃子の効果

いくら頭がよくても、行動的でも、エネルギーに満ちあふれていても、自分は一人しかいない。ものすごく成功したいのなら、世界に働きかける力を何倍にもしなくちゃならない。

 

木を守る

データを紙に閉じ込めたら、有用性に限界がある。

本で、データの死亡証明書と比喩されてたのはおもしろい表現だなと感じた。

 

lsコマンドでディレクトリにファイルが見つからないときにエラーが出ない話

lsでファイルがないときにエラーメッセージを出す必要はない。

｢明かりがついていない｣の代わりに｢部屋が暗い｣と言うようなものだ。

 

コンピュータの世界に昔からあるジョーク

1人の女性は、9ヶ月で子供1人を埋める。では、女性9人でかかれば1ヶ月で子供1人

を埋めますか?

 

 

 

UNIXという考え方―その設計思想と哲学