ほとんど未完

個人的な備忘録です。コーネルメソッドっぽく書くことを試してます。音声入力多用気味なので変換ミスとかはご容赦ください。

自分の理解の度合い(再掲)

このブログを、勉強の記録にしたいとおもってはじめます。

※このエントリはこのブログの最初のエントリでしたが、Markdown記法でゼロから書き直した都合上、3番目のエントリになりました。

勉強は多分物事を理解していくための行為だと思うので、以下の通り、私自身の物事の理解の段階を定義してみました。数字が大きいほど理解が深まった状態として定義しています。


  1. なんもしらん
  2. なんに使うかわからないけれど、名前など、断片的に引っかかる情報が2、3個でてくる
  3. ある物事を知覚した時、何のための物事なのか何となくわかる(例えばなんか平べったい丸いものを見た時、これは何かに蓋をするためのものだな、などと推測がつく)
  4. 名前も含めて、何に使うものなのか一例を説明できる。でも通り一遍の説明しかできない。類似の物事との区別までつけて、説明はできない
  5. 類似の物事と区別までつけて、教科書通りの概要や利用例を理解した上で説明できる
  6. 実際に使ったりしたことも含めて、教科書通りの説明のみならず、自身の知見も含めて説明できる
  7. 自身の知見のみならず、その物事のバックグラウンド、原理原則、原義、プロトコルまで把握した上で、質問が飛んできてもきちんと回答できるレベルで説明できる

基本的にはこれから勉強する全部の項目を7まで理解できれば良いので、こちらを目指していきます。 このブログの記事には、みかんマークをつけていますが、六番までできたと思ったら外します。

【🍊】AWS well architected frameworkについて

※このページは、自分の理解などを適宜更新していくためのページなので、間違ったことも書くかもしれないです。

AWSのベストプラクティスを以下6つの観点でまとめた文書のこと。何となくだけど頭文字とって「ウセシパコサ」で覚えそうになる。この歳になるとなかなか複数の単語を覚えられなくて。。。

  • 運用性:運用の中で開発をサポートして効果的に価値を提供するためのプロセスを改善し続けることのやり易さ
  • セキュリティ:単にリソースを保護するだけじゃなく、向上し続けることを含む。ちょっとゼロトラスト的な観点を含んでいる気がする
  • 信頼性:ワークロードが、きちんと動くことを保証すること
  • パフォーマンス効率:AWS上のリソース量に対してのパフォーマンスの最適化のこと。需給調整、新技術への対応も含んで動的に考えること
  • コスパ:コスパ
  • サステナビリティ:SDGs的な観点?

これらの観点は「柱」と言う表現で言及されていて、「鬼滅、、、?」と一瞬思ってしまったものの、運用性やセキュリティ、パフォーマンス効率などを読むと、 一度組んだらはい終わりではなく、生き物の様に変化していくことを前提にしていることが特徴的 と思った。

一般的な設計原則

Well-Architected frameworkで提供される設計の原則のこと。多分このフレームワークのゴールと思われる。

  • リソース利用実態に基づいてスケールの調整が可能なこと
  • 本稼働の規模を一時的に展開してテストできること
  • 自動化が出来ること
  • 変化に対応できるアーキテクチャ
  • アーキテクチャ変化の動機は収集データに基づいて行えること
  • 障害や過剰な負荷などのイベントをシミュレートしてテスト可能なこと(ゲームデイ)

コーネルメソッドってなんだ?

記憶力を良くするためのメソッド。らしいです。

「らしいです」と言うのは本で読み齧ったからであって、実は僕自身これをちゃんと理解していないのですが、以下の様なプロセスでノートを取ると記憶の定着がしやすくなる様です。


  • ノート:学んだことを、後から思い出しながら書く
  • キュー:学んだきっかけを書く
  • サマリー: ノートとキューを書いた後、翌日、それから1週間後に振り返って、原因と解決法を書く

この方法は最近読んで良かったと思った本に書いてあった方法です。

この方法を思い出すのにその本を毎度読み直していると今度はその本を読むことに没頭して時間を忘れてしまうので、本に記載された方法をもとに、自分のブログに簡潔に書いておくことにしました。

その本は「世界一流エンジニアの思考法」と言う本なので、また読みたくなったら読み直します。