230123
Y
- Ruby on Rails の勉強(Udemy)を終えた
- 141/141
- AWS のアカウントを作成した
- Ruby on Rails の勉強(Udemy)に付属していた AWS の操作の動画を見ながらユーザー設定、budgets の設定をした
- 次に手を動かすためのプロジェクトについて考えた
- CTO と 1on1 をした
- 買い出しに行ってきた
W
- Rails の動画を見終えても View 側の規約に関してはあまり良くわからなかった
- Rails の API モードを使って、RSS を収集するサーバを作るところから始めてみたいと思った
- Colud9 で API モードのプロジェクトを生成して、ローカルでは docker 環境を構築する
- 後のことを考えて、EC2 にデプロイする方法も調べる必要があると考えた
- 以前使っていたアカウントを解約したらもうつかえないことが分かった
- AWS のアカウント生成で分かったこと
- AWS のルートユーザーは基本的に操作しないことが分かった
- 代わりにお金周りの権限を除いた Admin アカウントを使って操作するのが一般的らしい
- budgets で一定金額まで課金が達したらアラートをしてくれる設定ができるのはありがたい
- MFA 設定をしておいて、ルートユーザーのアカウントが勝手に使われるのを防止する方法が分かった
- Ubuntu 環境の Cloud9 でソースコードを生成し、GitHub に push しておくと安定して Rails のコードが生成できることが分かった
- AWS のルートユーザーは基本的に操作しないことが分かった
- 技術的な課題を解決してあげる地位を確立して、テックリードという立場がありえる
- フロントエンドの牽引
- 技術的にリードする
- レビューする側に入ったほうがいいかもしれない
- 作業の平準化
- フロントエンドの牽引
- React に関する技術的な支援を期待している
- 会社のスタイルを確立する
- スケルトンプロジェクトを確立する
- コントリビュート、コーディングレギュレーションなども加える
- ジュニア層へのアプローチ
- スケルトンプロジェクトを確立する
- 計画、設計に関するキーワード
- 設計を残すフォーマット
- コミュニケーションの設計
- 設計の設計
- 開発現場における設計
- どういうドキュメントを残すのか
- 実装の設計
- 障害が出た場合のコミュニケーションの設計
- 成果物ベースでコミュニケーションをする
- 設計を残すフォーマット
- 仕組みに関するキーワード
- 技術部の仕組みづくり
- 発信、採用の仕組み
- 普段は買えない冷凍のロールキャベルが買えて、テンションが上った
T
- Colud9 で Ruby on Rails の API モードのプロジェクトを生成する
- EC2 へデプロイする方法について調べる
- tsconfig に設定する項目についてまとめる