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

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

DB設計で詰まったところ&どうやって理解したか

データベース

フィヨルドブートキャンプで、データベース設計(以下、DB設計)について学ぶプラクティスがあり、先日TwitterのDB設計の課題を合格したので、振り返りを書いた。

学習方法

  • 読んだ書籍
    • 『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』(ミック 著,翔泳社,2012年出版,全360ページ)
    • 『楽々ERDレッスン』(羽生 章洋 著,翔泳社,2006年出版,全240ページ)
  • 課題を解くために必要な部分を読む遅延評価法で学習した。一方の書籍に知りたい内容が載ってない時や疑問が出た時に、もう片方の書籍を読んで補完した。

理解に詰まったところ

1. 主キーは必ず一つのテーブルに一つだけと勘違いしていた

  • 『達人』の主キーの説明で、

主キーは一つのレコードを特定できるカラムの組合せ

と書いてあった。

  • しかし本に載っている、主キーを説明するテーブルには、主キーが一つのパターンしか載っていなかったので、主キーは一つのテーブルにつき一つだけと、勘違いしてしまった。
  • 勘違いしたまま『達人』の正規化の関数従属についての説明を読んだので、「主キーの一部」という言葉が出てきて混乱した。

どうやって理解したか

  • 以下の動画を見て、理解が誤っていたことに気づいた。
    • 主キー(わくわくアカデミー,2013/11/29投稿)
  • この記事の説明も分かりやすかった。

www.momoyama-usagi.com

  • 主キーは、一つのテーブルに一つある場合と複数ある場合がある。具体的には、主キーが何なのかについては、以下の記事に書いた。

saki-htr.hatenablog.com

2. ER図のリレーションシップ「1対0~多」の0とはどういう意味か

  • ER図のリレーションシップで、「1 対 0~多」の関係がある。 この「0」がどういう意味か理解するのが難しかった。

どうやって理解したか

  • テーブル同士の関係性を、現実に存在しているものに例えて考えてみると、分かりやすかった。
    Twitterの、ユーザーとツイートの関係について考える。

  • ユーザーから見た、ツイートとの関係

    • 1人のユーザーは、ツイートを複数回行うことができる。また、ツイートを1回もしないユーザーも存在する。よって、0~多。
  • ツイートから見た、ユーザーとの関係
    • 1つのツイートは、必ずだれか一人のユーザーが作成したものである。よって、1。
  • よって、ユーザー対ツイートの関係は、1対0~多である。

3. 外部キーはどうやって決めるのか

  • 『達人』を読む前に、『楽々ERDレッスン』の演習問題を解いたので、解説を読むと、いつの間にか外部キーができていて、ER図作成が完了しているので、過程がわからず混乱した。

どうやって理解したか

  • 外部キーは、正規化=関数従属を排除して新しいテーブルを作っていく中でできる。
  • 以下の解説動画を視聴して、関数従属を切り出して別にテーブルを作ることで、外部キーができることが分かった。

4. エンティティを抽出した後、どうやって正規化をすればいいのか分からなくなった

  • 『楽々ERDレッスン』の演習問題１を解いているところで、エンティティを抽出して、関連がありそうなカラムをテーブルに入れるところまで行った。

f:id:Saki-Htr:20210225151744p:plain

  • このテーブルの状態から、第3正規形まで正規化するにはどうすればいいか分からなくなった。
  • 自分の作ったテーブルと入れたカラムを見ただけでは、
    • どのカラムが主キーになるのか
    • どのカラムに2つ以上の値が入ってしまいそうか
    • どこに関数従属があるのか

が分からない。

どうやって理解したか

  • 上記の作ったテーブルに、色んなデータを登録してみたら、どこに複数のデータが入ってしまうのか分かりやすくなった。
  • 『達人』に載っていた正規化の説明が、一つのテーブルから始めていたので、作ったテーブル全てを一つのテーブルに入れてみた。

f:id:Saki-Htr:20210225152440p:plain

  • 実際にデータを登録する方法で方向性が間違っていないか、メンターさんにお聞きしたところ、「現場でも、実際にデータを入れてみて"あ！ここにミスある"って気づくことがある」と伺った。

感想

DB設計の手順を理解するのが難しかった

  • 課題を解く時に具体的なDB設計のやり方が分からなかった。
  • 『達人』でDB設計のやり方は、以下の4ステップと説明されていた。
1. エンティティ抽出
2. エンティティ定義
3. 正規化(~第3正規形まで)
4. ER図作成
  • しかし『達人』には、エンティティの抽出・定義の方法について詳しい説明が載っていなかった。
  • 逆に、『楽々ERDレッスン』には、エンティティの抽出方法についての説明はあったが、正規化とER図作成の手順については載っていなかった。
  • なので、具体的な手順を2冊の本を行き来して調べた。

本のどこが重要かの判断が難しかった

  • 私は分からない用語や理解できなかったことを全部日報に書いていた。そうしたら、メンターさんから「細かい言葉の定義はわかってなくていい」とか、「DB設計は仕事でよくやっているけど、「部分関数従属とか推移性関数従属とか意識して設計していない」、などアドバイスをいただいた。

  • 実際にTwitterのDB設計をした時に、「これは推移的関数従属だ」とか、「部分的関数従属だ」とかは意識していなかった。同じカラムが違うテーブルに複数ないようにすることを意識して設計することで完成できた。

  • 結局、自分が作ったテーブルに実際にデータを登録したときに不具合が起きないか&どういう風にデータを扱うかに重きを置くことが大事だと思った。

参考書籍/参考記事

Gitで課題提出するまでの手順をまとめた

Git･GitHub オススメ!

Gitの使い方を忘れてしまっていたので、復習。

用語解説

  • ローカル:自分のPC
  • リポジトリ：履歴に関するデータを保管している場所
  • ローカルリポジトリ:自分のPCにある、履歴データの保管場所
  • リモートリポジトリ:専用のサーバに配置して、複数人でファイルを共有するためのリポジトリ。ここではGitHubのリポジトリを指す。
  • ワークツリー:ファイルを編集する作業場。PCでコード編集していた場合、そこのことを指す。
  • インデックス:コミットするためのファイルを登録しておくためのスペース

Gitはどうやってファイルを管理しているのか?

  • Gitの目的は、変更履歴をたどれるようにすること
  • スナップショット(その時点の状態を、そのまま丸ごと保存したもの)で保存している

コミットするまでの手順

  • git initしてからコミットするまでの手順。

全体の流れ

# Gitに必要なファイルすべてを自動生成する
$ git init

# 変更をステージに追加する
$ git add

# 変更を記録する = コミットする
$ git commit

# ファイルの現在の変更状況を確認する
$ git status

1. git init

  • 実行は、ステージにあげたいディレクトリの直下で行う。
    例:sinatraメモアプリのコードをコミットしたいなら、/rubybook/sinatra_practice/で実行。
  • 何が起きるか?:Gitに必要なファイル(.gitディレクトリ)の全てが、このコマンドを実行したディレクトリの直下に自動生成される。
# /users/<ユーザー名>/rubybook/indexで実行
$ git init
Initialized empty Git repository in /Users/<ユーザー名>/rubybook/index/.git/

#=> 成功

# ls -aでファイルができているか確認
$ ls -a
./          ../         .git/       index.html
#=>.git/ができている

#.git/下に、Gitに必要なファイル全てが入っている
$ ls .git/
HEAD         config       description  hooks/       info/        objects/     refs/

2. git add

  • 何が起きるか?:変更をステージに追加する
# 今いるディレクトリ直下のファイル&ディレクトリ全てをステージに追加する
$ git add.

# ファイルやディレクトリを指定することもできる
$ git add <ファイル名>
$ git add <ディレクトリ名>

そもそもステージは何のためにあるか?

一部の変更だけをコミットしたい時、ワークツリーからステージにコミットしたい部分だけをステージにあげて、コミットするため。

3. git commit

  • 何が起きるか?:変更を記録する = コミットする
    ※git addでは、変更をステージに登録しただけで、まだ記録はされていない
$ git commit
#=>
[master (root-commit) 81fa678] initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 <コミットしたファイル>

# コミットメッセージを一緒に入力する
$ git commit -m "<メッセージ>"
  • これでコミットは完了。

git status でファイルの変更状況を確認

  • git addやgit commitする前に、どのファイルをadd&commitすべきか確認すべき。→git statusでファイルの変更状況を確認する。
  • ワークツリーとステージ間の変更状況、ステージとリポジトリ間の変更状況の、2つの情報を教えてくれる。

ワークツリーとステージ間

  • 前回ステージに追加=git addしてから、ワークツリーのファイルに変更があるかどうか、を教えてくれる。
  • git statusしたときに、Changes not staged for commit:：前回addされてからワークツリーに変更があって、それをまだgit addしてないよ！といっている。

ステージとリポジトリ間

  • 前回コミット=git commitしてから、ステージに新しく追加された=git addされたファイルがあるかどうか、を教えてくれる。
  • git statusしたときにChanges to be committed:：ステージに追加されているけど、まだコミットしてない変更があるよ!といっている。

例

実際にgit statusの結果がどうなっているか見てみる。

1.git commitまでしたファイルを編集して変更を加える

2.その後git statusで確認

$ git status
#=>
On branch master
Changes not staged for commit: #ステージに追加されてない変更があるよ！
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   index.html #$index.htmlに変更があったよ！
no changes added to commit (use "git add" and/or "git commit -a")


3.git addしてもう一度git statusを確認

$ git add .
$ git status
#=>
On branch master
Changes to be committed: #ステージに追加されているけど、まだコミットしてない変更があるよ!
  (use "git restore --staged <file>..." to unstage)
        modified:   index.html #該当するファイルはindex.html


4.git commit した後、git statusを確認

$ git status
#=>
On branch master
nothing to commit, working tree clean #コミットしてないファイルはありません

GitHubへアップロードする

  • git commitしたら、次にその内容をGitHub(リモートリポジトリ)にアップする。
  • GitHubにアップする理由
    • 自分が書いたコードを他の人に見てもらうため
    • ローカルリポジトリの内容をGitHubに保存しておくため

コミットしてからGitHubへアップするまでの手順

1.GitHub上で、保存したいリモートリポジトリを新規作成する。


2.アップする度に毎回リモートリポジトリのURLを指定するのは大変なので、ショートカットを作成する

$ git remote add origin <リモートリポジトリのURL>

  • これで、originというショートカットでアップできる。

  • 作成したショートカットの一覧確認と削除は以下のコマンドでできる。

# 作成したショートカットの一覧
$ git remote -v

# ショートカットの削除
$ git remote rm <ショートカット>


3.リモートリポジトリ(GitHub)へコミットしたファイルを送信する

git push <リモートリポジトリのショートカット名> <pushしたいローカルブランチ名>

# 例:originというショートカットに、mainブランチをpushする
git push origin main
  • ブランチが何かについては後で説明。

ブランチを作成してmainブランチにプルリクエストを送る

ブランチとは

  • ブランチとは、一つのプロジェクトから分岐させることにより、プロジェクト本体に影響を与えずに開発を行える機能のこと。並行で複数の機能を開発するために使う。
  • メリット:ブランチを作ることで、他の人の変更の影響を受けないですむ。
  • mainブランチ(旧:masterブランチ)はリリース用のブランチとし、開発はトピックごとにブランチを作って進める。 mainブランチで開発してしまうと、リリースしているコードがどれか分からなくなったり、一個前のリリースに戻れなくなってしまう。
    →そのため、ブランチを切って開発し、最終的にリリース用のmainブランチへマージする(コードを取り込む)という流れで開発を進める。

プルリクエストとは

  • プルリクエストとは:自分の変更したコードをリポジトリに取り込んでもらえるように、依頼すること。
  • 課題提出で、「READMEだけmainブランチにpushして、それ以外のファイルを開発用ブランチに保管してプルリクエストを送る」と指定があったのは、最終的には完成したコードをmainブランチに取り込むため。だからmainとは別に開発用のブランチを作る。

手順

1. ブランチを新規作成

# ブランチを新規作成
$ git branch <ブランチ名>

# 作ったブランチの一覧確認
$ git branch

# リモートブランチも表示
git branch -a
  • このコマンドは、作成をするだけで、切り替えはしない！

2. ブランチの切り替え

# 切り替え
$ git checkout <行きたいブランチ名>

# 作成してそのまま切り替えたい
$ git checkout -b <新規作成するブランチ名>

3. プルリクエストを送りたいファイルをgit add & git commit する

  • 作成したブランチに切り替える前に、絶対add&commitしない！

4. GitHubへpushする

$ git push <リモートリポジトリのショートカット名> <pushしたいローカルのブランチ名>

5. GitHub上でプルリクエストを作成する

ここからはターミナルではなく、GitHub上で操作する。

1.リモートリポジトリのPull requestsをクリック

2.New pull requestボタンをクリック

3.baseには取り込み先のブランチ(main)、compareには取り込んでほしい元のブランチを指定。

4.pull requestをクリック タイトルとメッセージを入力してcreateをクリック

(Revieweresでレビュワーを指定できるが、今回はしない)

参考書籍,参考教材

週報 2/15(月)~2/21(日)

2/15(月)~2/21(日)の一週間の学習の振り返りをざっくり。

今週の目標&結果

今週の目標 結果
sinatraメモアプリの合格 ◎ 20(土)に合格
WebアプリからのDB利用の合格 ✕ pgを使ったDB接続は完了
/prepared statementを利用した実装がまだ
Railsの教科書(約100P)を読み終わる ✕ 残り6~8章
DB設計について学んだことをブログに書く ✕
URLについて学んだことをブログに書く ✕

今週の学習時間

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

今週は目標時間をぴったり達成🎊

日付 目標 実際
2/15(月) 2:00 0:00
2/16(火) 2:00 3:00
2/17(水) 2:00 3:15
2/18(木) 6:00 9:30
2/19(金) 6:00 7:00
2/20(土) 6:00 7:15
2/21(日) 6:00 0:00
合計 30:00 30:00

今週やったこと

2/15(月)

やったこと

考えたこと

  • 目標を立てた時しか意識できてないので、忘れないように固定ツイートに貼った!これで忘れない💪

2/16(火)

やったこと

  • Railsの教科書p.1~20(1章の途中)
    • Railsをbundlerでインストール
    • rails new
    • rails sするために色々インストール&設定
  • 6:00-7:30 TeamGeek輪読会(最終回)

考えたこと

  • 1月頭から週3でやっていたTeamGeekの輪読会を読み終わった！読み終わって嬉しいが、終わってしまったのが悲しい。でもプラクティスを進めたいから、読みたい本ができるまでは、しばらく輪読会はお休みかなと思っている🤔
  • Railsの教科書が、とても丁寧で分かりやすい。
  • npm,Node.js,yarn,webpackerが何かわかってないので調べる。

2/17(水)

やったこと

  • rails sできるようにするために色々設定
    • nodeのバージョンを最新版から安定版にする
    • node -vとnodebrew lsの結果を同じにできた
  • rails g controller hello indexがうまくいかず →Webpacker can't find application.js とエラーが出たので解決にあたっていた

考えたこと

  • エラーメッセージを読んでも、そもそもwebpackerを初めて知ったので、何が原因か、どうしたら解決できるか分からなくて大変だった💦
  • 早くrails s ,rails gできるようになって学習を進めたい🥰

2/18(木) 休み

やったこと

  • rails -s できるようにするために設定いろいろ
    • 普段使ってるシェルをfish→bashへ変更
    • Error:homebrew-core is a shallow cloneを解決
    • railsコマンドが一切使えなくなったので解決。bundle installしたら直った
    • Rubyのバージョンを最新版3.0.0にアップデート
    • yarnをインストールしたらrails new,-s,-gできた
  • Railsの教科書:2-3章

考えたこと

  • なんとかrails new,-s,-gが実行できるようになった！
  • rbenvの切り替え方がわからず、ツイートしたところ、フィヨルドの方にアドバイスしていただいて、そもそもrbenvの仕様を理解していなかったことが原因と気づけた。アドバイスいただかなかったら気づけなかったと思うので、本当に感謝。
  • Railsの教科書、自分が実行したコマンドの裏側で何が起こっているか、非常に丁寧に解説してくれていて、Sinatraでやっていたのはこういうことだったのか〜と思いながら読んでいる。
  • コマンド数行でCRUD機能をもったメモが一瞬でできてびっくり仰天した🤯
  • fishシェルでrbenvのエラーが出たため、デフォルトシェルをfishに戻したが、自分がよく使うコマンドやディレクトリの候補を表示してくれたり、自分がいるGitのブランチを表示してくれたり、色々と便利なので、また戻そうか悩んでいる。
  • 30分弱仮眠したら午後も集中できた!睡眠は大事😄

2/19(金) 休み

やったこと

  • Railsの教科書
    • 4章完了
    • 5章途中(あと2pくらい)
  • Sinatraメモアプリのレビューを昼にいただいたので、修正
    • メモを新規作成するcreateメソッドと編集するeditメソッドがほぼ同じなので、createを消して、editのid部分を修正して新規作成時も使い回せるようにする
    • 提出物リンクリポジトリのトップなのでPRへのリンクに変更する。
    • PRページの下にREADME.mdがコンフリクトしていると警告が出ているので解消する→失敗
  • コンフリクトした原因が分からないので、提出時にどんなコマンドを実行したかを整理

考えたこと

  • Sinatraメモアプリ、プログラム自体には修正はほとんど無かったので嬉しかった！しかし、Gitのコンフリクトを修正できず、いろんなコマンドを試しているうちに、誤ってマージしてしまった💦Gitのプルリクエストを使った提出はこれが初めてで、操作に慣れていないので、実行するコマンドがどんな動作を行うのか理解してから実行すること、分からなければメンターさんに質問することを心がける。
  • Bookクラスのメソッド定義のコードはどこのファイルに書いてあるんだろう？と疑問だったが、「諸々の仕組みはRailsのActiveRecordが担ってくれていて、これを理解していこうとするともっと大変になるので、一旦ActiveRecordがとても便利だな、くらいの考えでもRails利用には支障がありません」とメンターさんから伺ったので、次に進む。

2/20(土)

やったこと

  • fishシェルを使いたいのでエラーの原因を調べた→未解決のまま
  • Sinatraが起動しなくなったので解決
    • brew postgresql-upgrade-databaseを実行
    • postgresql12をアンインストール
  • WebアプリからのDB利用
  • 昨日の日報提出

考えたこと

  • 昨日睡眠の質が微妙だったので、午後は集中力がかなり下がってWebアプリのDB利用はあまり進められなかった。今日はきちんと寝る！
  • URLもDBも知らない状態でいきなりrailsに入っていたら全然理解できなかったと思うので、おそろしい...
  • fishシェルが便利すぎて、やっぱりfishでruby,railsを使える方法がないか調べてたら時間がかかりそうだったので、後回し
  • 目の前のエラー解決は自分でできるようになったけど、その解決方法が長い目で見て良いかや、後々にこういう問題が起きてしまうかもということが分からないため、その場しのぎになっていないか不安。。というのもあって解決方法を細かく記録している。

2/21(日)

やったこと

  • 学習せず。

考えたこと

  • 木~土の3日間長時間学習していたので、4連休の最終日は力尽きてしまった...。目標の30時間は達成できたので良しとする。

今週の振り返り

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

  • sinatraメモアプリの合格
  • railsを問題なく使えるようになった
  • 今週はRailsがうまく使えなかったり、sinatraが起動しなくなったりと、エラー解決にあたることが多かった。Gitのコンフリクト以外は、全て自力で解決することができた💪

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

  • プラクティスを先に進めたいと思ってしまい、ブログでアウトプット等の復習が後回しになってしまっていたので、来週は復習する時間もきちんと確保する。長い目で見て、学んだことはしっかり振り返るべき。

来週の目標

Railsに本格的に入る前に復習に注力する。

  • データベース
    • TwitterのDB設計をどうやって行ったかまとめる
    • 他の受講生の提出物をチェック
    • 自己参照/自己結合の理解
    • 【ブログ】DB設計で学んだこと&詰まった点
  • REST
    • 【ブログ】web技術の基本/webを支える技術の感想
    • 【ブログ】URL設計で学んだこと
  • Git
    • 【ブログ】git init~プルリクエストの手順
  • 【ブログ】TeamGeekを輪読会の感想
  • 28(日)に必ず行う：2月の振り返り&計画の見直し

以下はできれば。

  • Railsの教科書の6~8章(最後)まで
  • book_appをリモートリポジトリのmainブランチにpushする

週報 2/8(月)~14(日)

2/8(月)~14(日)の一週間の学習の振り返りをざっくり。

今週の目標&結果

Sinatraでメモアプリを作る →目標達成✨

今週の目標 結果
メモに自動採番されるidをURLに組み込む。 ○
一覧画面でメモをクリックすると内容が見られるようにする ○
メモを編集できるようにする ○
メモを削除できるようにする ○
コードのクラス化 ○
PRGパターンで実装する ○

 

今週の学習時間

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

日付 目標 実際
8(月) 2:00 0:15
9(火) 2:00 1:45
10(水) 2:00 0:00
11(木) 6:00 7:15
12(金) 2:00 0:00
13(土) 6:00 0:00
14(日) 6:00 10:45
合計 26:00 20:00

 

今週やったこと

✅ 2/8(月)

やったこと

考えたこと

  • 金土日学習をしなかった自己嫌悪にひきずられて更に学習しなくなるのはまずい!と思い、リハビリをかねて出していなかった日報を提出した。

  • あんまり頑張れなかった週の振り返りブログは書きたくなかったが、頑張って書いた。書いたことで自分がなぜ学習できなかったか、どこに問題があったのか原因を明らかにでき、根拠なく落ち込まずにすんだので、よかった。文章を書くと頭と心の整理もできていいなと思った。

  • 漢方を飲むのを怠ったせいで、体調が悪化してしまい金土日はぐったりしていて一切学習できなかった。月曜朝に自己嫌悪に陥ったが、それについてツイートしたらフィヨルドの方々からたくさんふぁぼがきて、きっとみなさんも頑張れない日があって、毎日絶好調なわけではないんだな〜と元気をいただいた。

✅ 2/9(火)

やったこと

  • 6:10-7:10：TeamGeek輪読会
  • Sinatra
    • メソッド化したいコードを考える
    • jsonの中身をハッシュで取り出せたら便利と気づく
    • ①formのname＝titleとcontentに入れられた内容をハッシュに入れる→ハッシュをjsonに変換してmodel/id.jsonに書き込むメソッドを作
    • ②model/ に保管された各メモの情報が入ったjsonファイルからタイトルとメモ内容をハッシュ[キー]で取り出せるメソッドを作る
    • キーワード引数の復習

考えたこと

  • 久々に5時に起きて学習できた！
  • 落ち込んでるときはふさぎ込みがちだけれども、そういう時こそ人と話すことが大事だなと思った。輪読会に感謝。人と意見を交わすのは勉強になるし、自分とは違う考え方を知れてたのしい!
  • ✗「クラス化しなきゃ」→◎「 どんなコードを使い回せたら便利か」という視点で、クラス化・メソッド化を考えると分かりやすいと思った。そういえば、メソッド化についてQ&Aコーナーに投稿した時、「どう呼び出したいかで考えている」って答えてくださった方がいた。
  • 確定申告の処理が始まり、この日は久々に仕事が忙しく、疲れて夜は学習できなかった。結果的に終えられてホッとしている☺️ 仕事をしてない時間は学習に専念したいので、もう少しメンタルを切り替えられるようになりたい...。今回は、体調が悪い期間と被ったので、ダメージがいつもより大きかったと思う。ちゃんと漢方を毎日飲んで健康維持に努めようと思った💪

✅ 2/10(水)

やったこと

  • 学習せず。

考えたこと

  • この日は仕事が忙しいのと体調不良が重なり、学習できず。

✅ 2/11(木)

やったこと

  • Sinatra
    • 機能完成:メモのidをURLに組み込むことができた！
    • README作成
    • XSS対策
  • 6:00-7:00 TeamGeek輪読会

考えたこと

  • 週報ブログ 2/1(月)~2/7(日)で掲げていた今週の目標を達成した！idをurlに組み込んでからは、意外とすんなり実装できた。うれしい！

f:id:Saki-Htr:20210215180613p:plain

  • Bundlerを使ってインストールしたgemは、常にbundle execを冒頭につけて実行しなければいけないことが分かった。
  • 提出のために久々にGitをさわったら、Gitの仕組みやコマンドの意味をすっかり忘れてしまっていたので、明日から復習する！
  • sinatraで変数の中身がどうなってるか知りたい時にpデバッグするのが難しい。。lsコマンドの時はファイルが1つだったので、p 変数で簡単にできたが、sinatraからファイルが複数になって難しくなった。。
  • 今日はメモアプリを提出できる段階までもっていけた!まさか今日ここまで進むとは思わなかった。。タスクの洗い出しは事前にしていたものの、どこで詰まるか分からないため、思わぬところで詰まったり、意外なところが簡単に実装できたりして、学習計画を立てるのが難しかった...。
  • インスタンスメソッドとクラスメソッドの使い分け方が、プラクティスの記事を読んでもよくわからなかった。。しかし、今回の課題でクラス化・メソッド化ができるようになってきて、コードを書くのが楽しくなってきた。練習問題を探して解いてRubyの書き方をもっと身につけたい。

✅ 2/12(金)

  • 学習せず。

✅ 2/13(土)

やったこと

  • 6:00-7:00 TeamGeek輪読会

考えたこと

  • TeamGeek、次の回で読み終わる!週3で読んで約一ヶ月半で読み終わるので、良いペースだと思う。読み終わったら、読んだ感想をブログに書きたい💪

✅ 2/14(日)

やったこと

  • メモアプリ提出のため、gitの復習
  • Sinatraメモアプリの提出
  • 提出したファイルをコピーして、WebアプリからのDB利用を進めた。全部の機能が問題なく使えるところまでDBを使って実装できた。
  • 2/11(木),13(土),14(日)の日報提出

考えたこと

  • JSONファイルを使ったメモデータの管理、実装とても大変だったのに、pgを使ってDBに接続したら簡単にかけて感動した。 ハッシュをJSON形式に変換する必要もないし、自動採番のためにsecurerandomを使っていたが、データ型をserialにするだけで解決できたし、DB便利、すごい...と思った。
  • また、前のプラクティスで学んだデータベースが、アプリを作る時にどのように使われるのかも分かって、嬉しかった。これからRailsプラクティスでもっと複雑な機能を学習できると思うと、不安もあるがワクワクのほうが大きい。
  • 2月が半分終わってしまったが、今月は週報以外のブログを書けていない。DB設計,URL設計で学んだことを忘れないうちに今月中に書きたい。
  • 土曜から体調が良くなってきたので快適に学習できている✨いつも健康でいられるように気をつけたい。
  • 日報提出に思ったより時間がかかってしまい、週報ブログを日曜にかけなかった。  

    今週の振り返り

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

  • Sinatraメモアプリ、必須条件を達成し、提出した
  • Gitを復習して、仕組みや各コマンドが何を行っているかを思い出せた。忘れないように手順やそのコマンドが何を行っているかを詳細にメモしたので、提出物に問題がなければ、ブログに手順をまとめるつもり。
  • まだメモアプリの課題を合格していないが、プラクティス「WebアプリのDB利用」をやった。思ったより時間はかからなかった。最初、Rubyでどういうコードを書けばDBのテーブルにデータを登録したり、抜き出せたりできるのかが分からず、苦戦した。
  • 2月中にkaminariのプラクティスまでいく計画を立てているが、この調子だと達成できそう。課題のレビューを待っている間にRailsプラクティスを進めるつもり。
  • 次の火曜でTeamGeekを読み終わる✨去年の10月から始めた輪読、もう3冊目が読み終わると思うと感慨深い。

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

  • 最近朝起きた時にスマホをさわって、そのままやる気が削がれて学習を始められないことが多いので、なんとかしたい。。寝る前にスマホを別室に置いてスマホをアラームにしないほうがいいかもしれない。今日からやってみる。
  • 今週の目標達成のために今日何をすべきかの意識が、紙の手帳からTodoistアプリに移行してから薄れている。 Todoistだと、完了するとリストから削除されてしまい、やったことが把握できないので、Notionを使ってtodo管理してみようと思う。todoistは全てのtodoの備忘録、Notionは一週間のtodo管理として使ってみる。

来週の目標

  • sinatraメモアプリの合格
  • WebアプリからのDB利用の合格
  • 【レビューを待っている間に進める】Railsの教科書(約100P)を一通り実際に手を動かしながら読む。
  • DB設計について学んだことをブログに書く
  • URLについて学んだことをブログに書く

週報 2/1(月)~2/7(日)

2/1(月)~2/7(日)の一週間の学習の振り返りをざっくり。

今週の目標&結果

今週の目標 結果
Sinatraでメモアプリ作成の機能の完成 機能完成に至らず。
続きは、メモのidをURLに組み込むところから。

今週の学習時間

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

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

今週やったこと

2/1(月)

やったこと

  • メモ作成ごとにJSONファイルを新規作成 を実装
  • 一覧ページに、メモのタイトル名が、作成順に表示される を実装
  • 【Sinatra】<% ～ %>と<%= ～ %>の違いをまとめた

考えたこと

  • Sinatra、なんにもわからん状態から、何がわかれば解決できるかとか、エラーがこの辺で起きてるなーとかがわかってきた！
  • しかしエラーの見方が分からない。右上のメッセージで、ファイルとこの行がおかしいよーと言われてるのは分かったけど、それ以外何を意味してるか分からない。
  • get ~ endの中で定義した変数/インスタンス変数は別のところで使えるのか,,,? 使い回せるようにするためにクラスを作ってその中にインスタンス変数を作るべきってことなのかな。。オブジェクト指向とスコープが分かってない。 コードを書きなれておらず、書くのも読むのも遅いので、超入門の問題を解き直す。

2/2(火)

やったこと

  • 全ページの<h1>メモアプリ</h1>に、一覧に戻るリンクを貼る
  • メモ名と内容が入力されていない時は、登録できないようにする。 自動付番されるメモのidをURLに入れて、メモ一覧のメモ名にリンクを貼る →昨日書いたコードを使いまわしたいと思ったので、明日から、クラス,クラスメソッド,インスタンスメソッドを復習する
  • 復習の手順のタスクを作った。

f:id:Saki-Htr:20210208192358p:plain

プラクティス外

  • 6:00~7:15 TeamGeekの輪読会

考えたこと

  • Rubyの課題では、オブジェクト指向で書かなくてよかったので、超入門やチェリー本で学習したクラスやインスタンスまわりを忘れてしまったので、明日から復習する！実際に書けるようにならないと本当に理解したとは言えないなと思う。
  • ベタ書きだと上から読めばいいので、読みやすい&書きやすいが、Rubyの書き方に慣れていないので、「このメソッドや変数はそこから来たんだろう？」「このコードの戻り値はなんだろう？」と、コードを読み解くのにも時間がとてもかかっているので、Ruby力をつけたい。 Ruby超入門の物理本を買い直したので、問題も解き直す💪

2/3(水)

やったこと

  • Sinatraのメモアプリ:メモに自動採番されるIDをURLに使いたい。 →書いたコードを使いまわしたいと思ったので、コードを書く前にクラスの復習を先にすることにした。
  • クラスについてまとめた自分の日報を読む
  • インスタンスメソッドとクラスメソッドのちがいを思い出す
  • インスタンス変数について思い出す

考えたこと

  • クラス,クラスメソッド,インスタンスメソッド,インスタンス変数,initializeメソッドがどのようなものか思い出せた。久々なので不安だったが、一度理解できていると意外とすんなり理解できる。
  • 日報を書いた過去の自分に感謝。疑問を突き詰めて書いていたので我ながらわかりやすかった。
  • 自動採番されるメモIDをどうやってURLに組み込むにはどんなコードを書くか、イメージできていないので、それも手順を先に書く。頭の中でどう書くかイメージできていないと書くことはできない。
  • 明日は超入門のチャプター8を読んで解く。これを機会に物理本も買った！

2/4(木)

やったこと

  • クラス&ハッシュの復習
    • 超入門のch.8「クラス」を読む&解く
    • 超入門のch.6「ハッシュ」を読む&解く
    • 超入門7-3のキーワード引数を読んで理解
  • Sinatra
    • paramsを理解する
    • Sinatraの変数のスコープを調べる
    • idを各メモのurlに組み込むコードを考える

プラクティス外

  • 6:00-7:15 TeamGeek輪読会
  • Forkwellのイベント:Corporate Engineering​ Study #1 のyoutube動画を半分まで視聴

考えたこと

  • クラス、ハッシュの復習をした。オブジェクト指向で書かれたコードを読めるようになってきた

2/5(金)

  • 学習せず

2/6(土)

  • 学習せず

2/7(日)

  • 学習せず

今週の振り返り

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

  • JSONってそもそも何だろう？というところから、使い方や文書の構造が分かるところまで理解できた。Webを支える技術を読んで初めて知ったが、
  • ファイルが複数あるので、書きたい処理をどこに書けばいいかわからなくなったり、get ~ endやform action =に入れるURLに何を入れるかわからなくなったり、自分で作った変数がどこで作ってとんできたものか分からなくなったりと、混乱した。 が、混乱したときは書きたいコードの部分だけ全く別のファイルに書いてSinatra実行したりして、理解を深めた。
  • クラス,ハッシュの復習をした。一見遠回りに見えても復習は大事だと思った。遅かれ早かれオブジェクト指向で書けるようにならなければならないので、今からクラスやメソッドを使いこなせるようになりたいと思い、復習した。

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

  • 今週土日は体調が落ち込んでいたのもあり、ベッドから動けず全く学習しなかった。やらなかった時に週報を書くのは嫌だけど、自分を責めるためではなく、振り返るために書いているので、今リハビリのような感覚で週報を書いている。 文字に書きおこすと、なんとなくこうしなくちゃな〜と思って流していたことに対してちゃんと向き合えるので、"思う"だけでなく"行動"に結びつけられていいなと思った。
  • 体調改善のために2ヶ月くらい前から飲み始めた漢方を、最近飲むのをサボりがちだったので、今回また症状がぶり返してしまったのだと思う。反省。回復してくると飲むのを忘れてしまうので、今日からきちんと飲む。Amazonで買い足した！
  • 今週は朝早く目覚めても、スマホをいじってしまって気分が怠くなってしまったり、二度寝してしまうことが多かった。前になにかの記事でスマホにはやる気を奪う作用があるって見た...。気をつけねば。
    朝スマホをいじってしまわないように、目覚まし時計を買ったので、寝る前にタイムロッキングコンテナにスマホを入れてから寝て、朝起きたときに触れないようにして、家を出る直前くらいにロックが解除されるように設定しようと思う。目指せ脱・スマホ依存！

来週の目標

  • Sinatraのメモアプリ
    • メモに自動採番されるidをURLに組み込む。
    • 一覧画面でメモをクリックすると内容が見られるようにする
    • メモを編集できるようにする
    • メモを削除できるようにする
    • コードのクラス化
    • PRGパターンで実装する

ところまでいきたい！

週報 1/25(月)~1/31(日)

1/25(月)~1/31(日)の一週間の学習の振り返りをざっくり。

今週の目標&結果

今週の目標 結果
TwitterのURL設計 ○ 合格
Sinatraのメモアプリ 登録したメモをJSONファイルに保存する所で詰まる

今週の学習時間

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

日付 目標 実際
1/25(月) 2:00 2:45
1/26(火)休み 6:00 8:15
1/27(水) 2:00 0:00
1/28(木) 6:00 2:30
1/29(金) 2:00 0:00
1/30(土) 6:00 5:00
1/31(日) 6:00 2:45
合計 30:00 21:15

今週やったこと

1/25(月)

やったこと

  • URL設計の課題の再提出。気になることも合わせて質問。
  • XSSがなにか、Sinatraで対策するにはどうしたらいいか調べた
  • PRGパターンとは何かを調べた
  • 夜:techplay女子部のもくもく会に参加

考えたこと

  • メモアプリで、メモの保存ボタンや変更ボタンをおしたときに、データの保存とメモの一覧へのページ遷移が必要だと思っていたが、ここでPRGパターンの考え方が重要になってくると知ることができた。

1/26(火)

やったこと

考えたこと

  • モニターを2画面分割にして使ったらさらに快適になった🥰
  • Sinatraたのしい!早くGETメソッド以外も使いこなせるようになって、メモの機能を実装していきたい。

1/27(水)

  • この日は前日遅くまで起きていて、早起きに失敗&仕事後もだるくなってしまい学習しなかった。 やっぱり睡眠は大切。寝る前にスマホを触らない仕組みが必要と思った。

1/28(木)

やったこと

  • 6:00~7:00 TeamGeek輪読会(第11回):4~4.3を読んだ
  • メモの内容を保存するには色んな方法があるが、JSONが良いらしいので、JSONについて調べた

考えたこと

  • 登録したメモの内容をJSONファイルに保存するのが良さそうと思って調べたが、Sinatraにどのように書けばそれができるか分からず...。おそらくJSONファイルのハッシュのキーに、メモのID,タイトル,内容を設け、値に実際に登録したメモ内容を保存すると思うのだが、そもそもJSONの扱い方がよく分かっていない...。 →JSON.parseを調べたら良さそうとメンターさんからアドバイスいただいたので、調べる

1/29(金)

  • 今日は学習せず。JSONファイルに入力内容を保存することができるのか、不安なものあり学習への意欲が下がっている...。タスク洗い出しはしたものの、Sinatraを初めてさわるため、手順が明確にわかっていないため、進捗状況が見えづらいのも不安。

1/30(土)

やったこと

  • 6:00~7:00 TeamGeekの輪読会
  • 8:30~10:00 Hirakata.rbに参加
  • 本:Sinatra入門のじゃんけんアプリを作る
  • RailsGirlsのチュートリアルの投票アプリを作る
    • ハッシュをeachで回すとどうなるか調べる
    • yamlとはなにか/使い方を知る
  • JSONでのメモ保存方法を調べる

考えたこと

  • erbファイルに書くコードがhtmlとRubyが混ざっているので、自分がHTMLを書いてるのかrubyを書いてるのかわからなくなる...
  • たくさんファイルがあるので、「この変数の出どころはどこだろう」と混乱する...
  • なかなかJSONでのメモ保存方法がわからず焦る😓

1/31(日)

やったこと

考えたこと

  • Rubyのハッシュを使ったJSONファイルへの書き込み方がやっと分かったので、これを皮切りに登録したメモごとにハッシュ作成もしくはファイル作成して、IDを自動で付与するコードも書けるようにしたい。

今週の振り返り

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

  • TwitterのURL設計を合格した
  • XSSがなにか分かった
  • PRGパターンがなにか分かった
  • Bundlerの使い方を復習した
  • HTMLのformの使い方を復習した
  • formに入力した内容を、ハッシュの値に入れる→JSON形式に変換→JSONファイルに保存するコードは書けた
  • メモのIDを自動採番する方法がわかった
  • 火曜はコワーキングスペースで学習したら長時間学習に集中できた。
  • タスク&時間管理に、Toggl,Todoist,Googleカレンダーを連携して使い始めたが、タスクを整理してtodoistに登録したら、やるべきことが明確になり、後でやろうと思って忘れることを防止できてよかった。 f:id:Saki-Htr:20210131193710p:plain

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

  • 参考記事を読んでもやりたいことの実現方法がわからない場合、やりたいことを細分化して言語化したり、図に書いたりして整理すればよかった。先週のLT会
  • Sinatraメモアプリを進める上で、外部モニターがあった方が学習しやすいので、自宅で学習していたが、ベッドがすぐ近くにあることもあり集中力が続かなかったので、コワーキングスペースなど人目がある場所で学習しようと思った。
  • また、意欲が下がってきて学習しない日が続くと、着手するのが更に億劫になったり、再開するときに思い出すのが大変になるなど、かなりのタイムロスになってしまうので、毎日少しずつでもすすめることを心がける。
  • 今週は火曜に有給を取るなど、学習できる時間が多かったはずだが、Sinatraがなかなかうまく行かず学習意欲が下がってきてしまい、あまり長時間は学習できなかった。
  • タスク&時間管理に、Toggl,Todoist,Googleカレンダーを使い始めたが、一週間の目標設定と、それに対しての日々の進捗状況の見える化がうまくできなかったので、
    • タスクの登録はtodoist
    • 勉強会やイベントなど既に決まっている予定はGoogleカレンダー
    • 学習時間はToggl に登録して、
      一週間の目標設定と、そのために具体的に何をやるかはバーチカル手帳に書くことにする。 今週は、Sinatraをいつまでにどの程度すすめるかの目標設定が甘かった。

来週の目標

Sinatraでメモアプリ作成の機能の完成
READMEの作成、XSSの対策、提出するためのGit復習は必須にしないことにする。

新しいLinuxの教科書を読む会 #9 に参加させていただいた感想

Linux 勉強会・イベント

はじめに

1/24(日)に開催された「新しいLinuxの教科書」を読む会 #9に参加させていただいた。

linuxbook.connpass.com

勉強会の中で、著者のお一人である大角さんが、相手に伝わりやすい文章の書き方について教えてくださったので、そちらについて感想を書いた。

『文章、作文技法、リモートワーク』

こちらが大角さんの発表資料。

speakerdeck.com


【Point】
1. 相手の脳に負担をかけない
2. 相手が答えやすい/相手が「自分が何をすればいいか」すぐ分かる
3. 自分がこれを受け取ったら？と、頭をいったん真っ白にして考える

リモートワークになって、必要とされるスキルが変わった

コロナ禍でリモートワークが増えたことで、仕事での必須スキルが対面のコミュニケーション力から、 伝わりやすい文章を書く力に変わった。


たしかに対面だと、「なんとなく」でニュアンスを伝えられたり、PC画面や書類を見せれば何について話をしようとしているか分かるなど、きちんと言語化できていなくても意思疎通がしやすいな、と思った。

1. 結論から書く

なぜ結論から書くべきかの理由の一つとして、「相手がどういった端末でそのメールを見るか分からないから」という話が印象的だった。 PCだとすべての文章を大きい画面で見ることができるが、スマートフォンやアップルウォッチでは、メール通知の画面では、件名や最初の数行しか見ることができない。
私は普段している仕事がデスクワークのため、スマートフォンでメールを確認することが滅多になかったのもあり、このような観点からメール文について考えたことがなかった。 営業の方々は外出が頻繁にあるため、メール通知を見た時点で内容が伝わる文章を書くように気をつけようと思った。

2. メールはだらだら書かない

メールの文頭に、「報告」「質問」「依頼」「相談」などの「小見出し」を付けたほうが分かりやすいという話が非常に参考になった。
文章が長い場合はとくに、小見出しをつけると、どの辺りに自分が欲しい情報が書かれているかが分かり、文章全体の構成が分かって読みやすいと思ったので、仕事でも取り入れたいと思った。

3. 質問・指示は、番号で箇条書きにすると、相手が答えやすい

質問したいことが複数ある場合、番号をつけて箇条書きにすると分かりやすいという話が参考になった。
今までは、質問が複数あるときは、「〇〇について伺いたいです。また、△△についてですが~」というように、「また、」を間に入れて書いていたが、 ラベリングをしたほうが、何個質問をされているかがひと目で分かって良いと思った。

4. メールの件名は主題

件名には小見出しをつけると分かりやすいという話が参考になった。
私はこれまで小見出しはつけずにメールを送っていたが、例えば営業の方当てに電話があった時は、お客様への折返しが必要かどうかを小見出しに書くと見やすいと思ったので、仕事に取り入れていこうと思った。

5. 主語・目的語を省略しない

主語・目的語を省略して、「○○した？」と送ると、相手に「怒っている」と思わることがあるので、省略しない。

たしかに、文章だと言い回しによってはきつい印象を与えることがあるので、「自分がこの文章を送られたらどんな気持ちになるか」を意識して書こうと思った。

目次はスライドの最後に入れる

発表の最後にはだいたい質問があるので、スライドの最後には、"ご清聴ありがとうございました"ではなく、目次を入れるべきという話が参考になった。
今年はLTにも挑戦したいと思っているので、自分が発表する時には、目次を一番最初と最後の両方に入れて、質問タイムの時にすぐに目次を表示できるようにしておこうと思った。

おわりに

普段の仕事では、メールを送られることよりも、送って読んでもらうことのほうが圧倒的に多いため、これまでどんな文章だと伝わりやすいかを考えたことがあまりなかった。 そのため、今回伝わりやすい文章を書くことの重要性と、 どんな工夫をすると伝わりやすいかのポイントを知ることができて、非常に勉強になった。 また、今回教わった方法は、仕事だけでなく、プログラミングスクールで分からないことを質問する時にも役に立つと思うので、積極的に使っていきたいと思う。