Sakiのプログラミング学習ブログ

プログラミングについて学んだことや、学習の振返りを書いています。

週報 1/4(月)~1/10(日)

1/4(月)~1/10(日)の一週間の学習の振り返りをざっくり行った。

今週の目標&結果

今週の目標 結果
正規化ができるようになる ◯
TwitterのDB設計の課題を提出する △ 今週中に提出できず(1/11(月)に提出)

今週の学習時間

プラクティス外の学習・勉強会への参加は含めない。

日付 目標 実際
1/4(月) 2:00 3:15
1/5(火) 2:00 2:30
1/6(水) 2:00 1:15
1/7(木) 6:00 6:15
1/8(金) 2:00 3:30
1/9(土) 6:00 5:45
1/10(日) 6:00 5:30
合計 26:00 28:00

今週やったことや考えたこと色々

1/4(月)

1/5(火)

  • 演習問題１を解く
    • イベント系エンティティとリソース系エンティティの抽出
    • 項目(カラム)をテーブルに入れる
    • postgresqlで↑のテーブル作成
      • 忘れていたpostgresqlの操作を思い出した。登録したいものを実際に操作すると良いアウトプットになると思った。
      • テーブル作成でカラムを同時に複数する操作と、主キー,not nullの制約をつけたカラムを登録する操作に手間どり、時間がかかった。
  • 日報で質問した。エンティティを抽出した後正規化のやり方がわからず、想定される様々なレコードを登録してみて、どのカラムが主キーになるかや、どこに関数従属があるかを見つけて正規化しようと思っているが、方向性が合っているか聞いた。 →良いと思うと言っていただけた。設計してデータ入れてみたら矛盾に気づく事も多いらしい。
  • 6:00~7:00 TeamGeek輪読会(第1回)

1/6(水)

1/7(木)

  • 昨日の日報提出
  • 演習問題1の自分で作ったテーブルに色んなレコードを登録してみる
  • 雑談ルームで質問
    • 自分で作った第1正規形の主キーが分からなくなった
    • 質問した際に、回答してくださった方が仰ったことと、それを聞いた自分の理解が同じかどうか確認する作業はとても大事だなと思った。前に、「質問は"このように理解しましたがあってますか？"だけでも十分です」とアドバイスされたことを思い出した。前回質問した時よりもそれができていて、話の認識がずれずに済んだと思う。
  • 非正規系→第3正規形まで正規化
  • 答えと違う点を整理して質問
  • この前質問した時よりも、DB設計の理解が進んでいると褒められた。嬉しい。
  • 「達人」と「楽々」で正規化する前のテーブルの状態がちがうので、とまどった。 達人は一つの大きなテーブルにすべてのカラムが詰め込まれている。楽々はイベント系エンティティとリソース系エンティティに分けている。 →達人のやり方のほうでやったほうがいいとアドバイスいただいた。
  • エンジニアの重要な仕事は「ビジネス側へのヒアリング」と「言語化」なので、身につけるべき知識だと教わる
  • 6:00~7:00 TeamGeek輪読会(第2回)

1/8(金)

  • 自分が作った第3正規形と楽々の答えの違いを整理して昨日の日報で質問
  • TwitterのDB設計に取り掛かる
    • Q&Aや参考記事を読んだ
    • 機能の洗い出し(途中)
  • この日は仕事後集中できずPCに向かっていても、ぼーっとしてしまったので、課題を進めるのは諦めて、ブログを書くか後回しにしていた庶務をやった方が良かったかも。

1/9(土)

  • Twitterの機能洗い出し
  • 機能ごとにテーブルを作り、各テーブルに項目(カラム)を入れてみる
  • 項目を入れるところでミュート・ブロック・いいね・リツイート機能などのテーブルに、どういったカラムを入れればよいのか行き詰まり、中間テーブルと自己参照が必要なことに気がつけた]
  • 6:00~7:00 TeamGeek輪読会(第3回)
  • 14:15~14:45 達人に学ぶDB設計の輪読会の予習
  • 22:00~23:00 達人に学ぶDb設 輪読会(第2回)
    • 1回目よりは積極的に参加・発言できた
    • なんとなく理解していたスキーマが3層である理由がわかった。
  • twitterのDB設計ができるか不安なのと、寒いせいかぼーっとしてしまいなかなか学習に入れなかった。 分からないことを理解するという行為そのものよりも、分からなかったらどうしようという不安が私にとってハードルになっている。 書籍や参考記事を読む中で理解することができてきた(少なくとも課題はクリアした)、という成功体験を積んできたはずなのに、分からないことへの不安・恐怖になかなか慣れないなと感じる。

1/10(日)

  • 多対多、中間テーブル、自己参照/自己結合の理解
    • 中間テーブルを理解できた!想像していたよりも難しくなくてホッとした。自分で中間テーブルを作って登録してみると理解が深まってよかった。
    • 自己参照/自己結合は、完全には理解できなかった
  • ER図の見方を少し忘れていたので復習
  • 一週間ごとの週報ブログのフォーマット作成
  • 中間テーブル、自己参照/自己結合をtwitterのDB設計の課題に組み込んだ。

今週の振り返り

✅ できたこと/できるようになったこと

  • postgresqlの操作に慣れた
  • 今週に課題提出するという目標を設定していたので、今質問しないとタイムロスになるという思考が働き、どんどん質問できた。
    • 質問を日報で2回、雑談ルームで1回した
  • 正規化を理解はしているが実践はできてない状態から課題提出まで行けた
  • 自分で作ったテーブルにレコードを登録してみたら正規化の理解がとても深まった
  • TwitterのDB設計をかなり進められた
  • 多対多、中間テーブルを理解した
  • 自己参照/自己結合を完全には理解できていないが、課題に組み込めるレベルまでは理解できた
  • 目標学習時間を上回った

    ✅ "こうしたらもっと良かった"と思うこと

  • テーブルへのレコード登録と課題作成にあたって、Postgresqlを使う必要がなかったので、タイムロスだった。 (しかし後のプラクティスで絶対操作することになるので、慣れられたのはよかった)
  • 目標は明確だったが、やることの内訳は不明確だった(DB設計の手順の理解が難しかったのもあり、明確にできなかった)
  • 仕事後の集中できない時間は、課題作成ではなく、ブログを書くか後回しにしていた庶務をやった方が良かったかも。

    考えたこと

  • 家で学習するときは、スマホをタイムロッキングコンテナに入れたほうがずっと集中できることが分かった。
  • 睡眠の質確保のため、寝る前のカフェイン排除&入浴は必須と分かった
  • 意外と夜のほうが集中できることが分かったので、休日は無理に早起きしないことにした

来週の目標

DB設計の復習中心。

  • TwitterのDB設計を合格する
  • DB設計で学んだことをブログに書く
    • draw.ioの使い方備忘
    • 用語の整理
    • 正規化の手順
    • ER図の見方
    • DB設計の手順
    • 中間テーブル
    • 自己参照/自己結合
    • 自分がDB設計で理解につまずいた所&どうやって理解したか
      このあたりをまとめたい。