Posts

.1. AWSを学ぶべき理由 .1.1. プログラミングの本質ではない、環境構築を不要にできる .1.2. 知識を資格として証明できる。 .2. AWS認定資格 .2.1. 取得したい資格No.1である .2.2. 稼げる資格である .3. AWS Academyで学ぶべき理由 .3.1. AWS資格試験に準拠したカリキュラムで学べる .3.2. 無料で学べる .3.3. 資格試験受験料の割引がある さいごに AWSの魅力、そしてAWSを学習する魅力をお伝えしたい。 .1. AWSを学ぶべき理由 .1.1. プログラミングの本質ではない、環境構築を不要にできる 42Tokyoの学生であれば、サーバの管理がいかに複雑で、難易度が高いかを、よく理解していると思う。 AWSを学べば、サーバの管理を不要にし、アプリケーションのデプロイが簡単にできる。 .1.2. 知識を資格として証明できる。 AWSには、認定制度が存在する。 基礎からプロフェッショナル、専門知識まで11種類の資格に分かれており、順番に取得することで確実な学びの証明とすることができる。 .2. AWS認定資格 ここでAWS認定を取得するメリットについて整理する。 .2.1. 取得したい資格No.1である こちらの記事によると、AWSの認定資格は取得したい資格のNo.1である。 No.2以降を見ていくと、情報処理試験の高度資格が並んでおり、AWS資格が相当注目されていることがわかる。 .2.2. 稼げる資格である こちらによると 「AWS認定ソリューションアーキテクト アソシエイト」取得者の平均給与は$149,446（約1700万円）である。 紛うことなき高収入資格である。 .3. AWS Academyで学ぶべき理由 ここからが本題である。 AWS Academyで学ぶべき理由を解説していく。 .3.1. AWS資格試験に準拠したカリキュラムで学べる 注目されている資格を目指して、ムダなく一直線に学ぶことができる。 AWS Academyでは基礎資格である「クラウドプラクティショナー」や中級資格の「ソリューションアーキテクト アソシエイト」の学習が可能である。 .3.2. 無料で学べる AWS Academyのカリキュラムはすべて無料である。 カリキュラムには以下のものが含まれている。 講師による講義 デモ映像 自由に操作できるラボ環境 確認テストによる、知識の確認 繰り返す。全て無料である。 .3.3. 資格試験受験料の割引がある AWS Academyのカリキュラムを修了した学生は割引券（バウチャー）を受け取ることができる。 このバウチャーで資格試験受験料が 50% 割引となる。 これは $50〜$150 の価値があり、これが無料で手に入るチャンスである。 ...

構想力が劇的に高まる アーキテクト思考 はじめに 発売当初からタイトルが気になっていた一冊。 その中でも、読んでみて共感した部分を中心にまとめる。 目的 ソフトウェアアーキテクチャの目的は、求められているシステムを構築・保守するために必要な人材を最小限に抑えることである。 p.34 とてもいい定義だと思う。 原理原則に基づく議論に対して、具体的な指針を与えてくれる。 再構築 自信過剰による再設計は、元のプロジェクトと同じように崩壊する。 p.40 自信過剰による再設計というのがとても絶妙である。 再設計をするというくらいなので、一度失敗をしてるのであろう。 その瞬間に思いつくのは「目の前の課題に対応した設計」だろう。 ただ、再構築が必要ということはそもそもがイマイチだったはずなので、ガラッと変える必要があるのである。 このガラッと変える、が難しいのだなと感じた。 構想力が劇的に高まる アーキテクト思考

構想力が劇的に高まる アーキテクト思考 はじめに 発売当初からタイトルが気になっていた一冊。 その中でも、読んでみて共感した部分を中心にまとめる。 Why, What, How アーキテクト思考のWhy, What, Howを明らかにする。 p.20 見出しより引用。 よく使われている切り口であるWhy,What,How。 ただ、他の書籍ではWhy,How,Whatという順番で物事を整理していることが多い。 私は、このことに強烈に違和感を覚えていた。 本書の切り口である、Why,What,Howという順番で物事を捉えている方がいらっしゃることに嬉しさを感じた。 具体と抽象 アーキテクト思考の実態とは（略）「具体と抽象を行き来しながら新たな知的成果物を生み出していくこと」であると定義します。 p.105 さらに本書では、具体と抽象の例として以下を例示している。 カテゴリーと個別事象 目的と手段 全体と部分 よくあるフレームワークをまとめて考えられるメタフレームワークとでも呼べる考え方だなと思った。 上記記載後、読み進めていくとp.150で「第一原理思考」という用語が与えられていたので、さらに共感した。 フレームワーク アーキテクト思考　＋　フレームワーク　＝　全体構想と優先順位付け 非アーキテクト思考＋　フレームワーク　＝　単なる機械的穴埋め p.118 これも強く共感したフレーズ。 フレームワークに登場する要素全てが等しく重要なのではなく、濃淡があるのである。 とくに、淡い要素については、考慮漏れがないかだけ確認できればいい。それがフレームワークの使い方であるべきである。 すこし違う話だが、ビジネスモデルキャンバスは埋める順番が決まっている。 順番に（優先順位をつけて）考えることまで含めてフレームワーク、となっている点がとてもいいと思った。 さいごに もやっと理解していたことをスッキリと整理してくれている一冊。 ビジネス入門書としてもいいのかなと思う。 構想力が劇的に高まる アーキテクト思考

.1. はじめに .2. 事前準備編 .2.1. タスクの分類の整理 .2.2. todoリストの作成 .2. タスク管理編 .2.1. タスク発生時にどうするか。 .2.2. 整理の時間に何をするか。 .2.3. タスク実行時に何をするか。 .1. はじめに タスク管理手法を説明したら、「わかりにくい」と複数人に言われた。 なので、なるべくわかりやすく説明することを目標に整理する。 コンセプトは以下の通り。 記憶は信用しない。 すべてtodoリストにある、という安心感が集中力につながる。 .2. 事前準備編 事前準備を行う。 .2.1. タスクの分類の整理 まずは分類を思い浮かべてみる。 分類がそのまま"リスト"になる。 たとえば、以下のような分類がある。 今、思いついたやりたいこと。(すぐ終わりそうなもの） 今、思いついたやりたいこと。(複数のステップを踏まないといけないもの） 今すぐできるタスク。 他の人に依頼するタスク。 他の人に依頼していて返事待ちのタスク。 毎日繰り返すタスク。 今すぐには実行できないけど、ある特定の日に実行したいタスク。 プロジェクト。「学校の卒業」「筋トレ」など、長期的に達成したい大きな目標。 .2.2. todoリストの作成 inbox 要詳細化 プロジェクト（プロジェクトごとにリストを作る） 依頼する 連絡待ち 今すぐできる いつかやる アラート リスト一覧 .2. タスク管理編 .2.1. タスク発生時にどうするか。 inboxに入れる。 どんなこともinboxにいれる。ここ以外見る必要があるときは「〇〇を確認する」というタスクをinboxに入れる。 .2.2. 整理の時間に何をするか。 inboxを空にする。 inboxのタスクは必ず他のリストへ移動させる。 移動時のポイントは以下の通り。 タスク分割が必要なタスク → 「要詳細化」へ移動。 プロジェクトに含まれるタスク → 「プロジェクト」へ移動。 毎日繰り返すタスク → 「アラート」へ移動。 今すぐには実行できないけど、ある特定の日に実行したいタスク → 「アラート」へ移動。 「連絡待ち」の期限を確認。 期限が近いものについては、「依頼する」へ移動させて後ほどリマインドを送る。 ...

予備校なんてぶっ潰そうぜ。 はじめに 最近はまっている「ゆる言語学ラジオ」で紹介されていたので気になった本。 起業の辛い面や、プロダクト開発の厳しい面を生々しい表現で書かれている。 心に残った言葉 急ごしらえの泥舟には、誰も一緒に乗ってくれない p.49 人がいなくなるたびに、いちいち心の柔らかい部分をさらけけ出して傷ついていたら、キリがないからだ。 p.79 立ち上げ当初の人集めの難しさを表した言葉。初期メンバーはスキルセットも価値観も進め方も人生の状態もマッチしていないと厳しいよね・・と感じた。 プログラムを産み落として神様になった後は、容赦のないフィードバックに打ちのめされ、泥水に叩きつけられる敗北感を味わう。 p.67 ソフトウェアエンジニアあるあるだと思う。 完成後の万能感と現実とのギャップ。。 さいごに 42Tokyoでは、ソースコードのピアレビューを行います。レビューを通して、成果物の誤りを適切に指摘してもらえるので、（多くの学びと引き換えに）現実を知ることができます😄 予備校なんてぶっ潰そうぜ。