1/11(月)~1/17(日)の一週間の学習の振り返りをざっくり。
今週の目標&結果
今週の目標 | 結果 |
---|---|
TwitterのDB設計を合格する | 提出物の画像のURIを間違えたため、まだレビューをしていただいていない |
記事:draw.ioの使い方備忘 | ○ |
記事:正規化の手順 | 主キー/外部キーを先に書いた方がいいと思ったため、途中 |
記事:主キーとは | ○ |
記事:外部キー | ✗ |
記事:DB設計の手順 | 提出物合格してから書こうと思ったため✗ |
記事:中間テーブル | ○ |
記事:自己参照/自己結合 | 理解できていないため✗ |
記事:自分がDB設計で理解につまずいた所&どうやって理解したか | 途中/合格してから書く |
今週の学習時間
プラクティス外の学習・勉強会への参加は含めない。
日付 | 目標 | 実際 |
---|---|---|
1/11(月) | 6:00 | 5:15 |
1/12(火) | 2:00 | 1:30 |
1/13(水) | 2:00 | 4:00 |
1/14(木) | 6:00 | 5:45 |
1/15(金) | 2:00 | 2:45 |
1/16(土) | 6:00 | 2:45 |
1/17(日) | 6:00 | 4:45 |
合計 | 30:00 | 25:00 |
今週やったこと
1/11(月)
- TwitterのDB設計のER図を提出した
- draw.ioの使い方をブログに書いた
- 自己参照/自己結合の理解ができなかった
プラクティス外
- 週報をブログに書いた
1/12(火)
- ブログ書くために日報と達人を読み返した
プラクティス外
- 6:00-7:00 TeamGeek 輪読会
- 19:30-21:00 健康LT第2弾:仕事の疲れ&睡眠について語ろうLT雑談会 #techplaygirlsに参加
- 22:00-22:30 日報のまとめ
- プログラミングスクール生へ、採用の現場よりを読んで気になった所。
「今日やったこと!」的なlogをTwitterで見せるくらいなら、ブログなんかに書いたほうがいい。 なぜかというと、どんなことを学んで、どんなところで失敗し、次にどう活かすかをまとめる技術って、仕事で活きてくるのよね。 それを140字でやれるならすごいけど、いわゆる学んだ過程はしっかりひとつの記事にまとめたほうが結果として自分の身になると思う(し、書類審査側も面接官のエンジニアへのトスアップが判断がしやすい)
→週報ブログもこれに当たると思うので、続けていこうと思った。 - 睡眠の質向上には、朝の15分の散歩が一番効果的だったと教えていただいた
1/13(水)
- データベースに関してブログ記事作成
- データベースに関する用語まとめ:そもそもデータベースとは何なのか?今課題でやっているデータベース設計はシステム開発の中でどういう位置づけなのか、テーブルなどの用語について自分なりの言葉にしてまとめた。
- SQLコマンドまとめ:毎回調べるのは大変なので、一つの記事にまとめた。データベースの操作、テーブルの操作、カラムの操作、SQL構文、句のまとめ。 今日は仕事後の集中力がなかったので、急遽正規化の記事ではなくSQLコマンド集の記事を書いた。
プラクティス外
- 21:00~23:00 Fukuoka.rb #192に参加させていただいた
1/14(木)
- 正規化」の記事を書いた(途中)
- 「主キー」を説明する記事を書いた:【DB設計】 主キーとは
- DB設計はOne Fact in One Place(1つの事実は1つの場所に)。これを徹底すると正規化される。
プラクティス外
- 6:00~7:00 TeamGeek輪読会
- 16:00~17:00 雑談ルーム参加
- イベントに申し込んだ:Mercari’s Women in Tech Meetup Vol.03
学んだこと
- 正規化しないとどうなるか?:一つの事実が複数の箇所にあると複数の箇所を同時に常に更新していかないといけない。
→複数あるとどこか一つに登録し忘れた時に不具合が起こってしまって大変だと思った。 - 現在の仕事のやり方ではDB設計してからコード書くことはしない。きっちり設計したところでどうせ変わるので、ボトムアップでちょっとずつテーブル増やしたりカラム追加したりしながら作ることが多い。
- Railsは主キーは必ず自動採番の数値データ。キー自体に意味をもたせることが基本的にない。この辺はデータベースの本に書いてあるようなこととは随分印象が違うかも。
→Railsのプラクティスに入ったらまたDBに対する理解が深まりそうと思った - DB設計を先にきっちり設計しているのはウォーターフォール形式の開発だけという傾向はあるかも。後は分野にもよる。
- TeamGeekで、「積極的にチームとコミュニケーションをとって、自分の仕事を知ってもらうようにしよう」とあった。 たしかに、
→たしかに仕事でも学習でも、その人が何がわからなくて困っているかはその人にしかわからないので、積極的に発信した方が良いな、と思った。
1/15(金)
- 大名エンジニアカレッジの特別編:データベースを視聴
1/16(土)
- 中間テーブルについて学んだことをブログに書いた:【DB設計】 中間テーブルとは
プラクティス外
- 6:00~7:00 TeamGeek輪読会
- 睡眠の質向上のため、朝30分お散歩に行ってきた
1/17(日)
- TwitterのDB設計で誤りに気づいたので、追加修正した
今週の振り返り
✅ できたこと/できるようになったこと
- 初めて地域rbに参加した。
- 質問することにためらいが無くなってきた
- 今週は体調不良にしては記事作成などがんばれたと思う
- DB設計に関する記事を4つ書けた。記事を書くなかで、なんとなく理解していてきちんと説明できない所が浮き彫りになった。
- 土曜から休日の朝散歩を始めた
- 睡眠の質向上のためのTipsについてたくさん知れた
✅ "こうしたらもっと良かった"と思うこと
- Fukuoka.rb #192に参加させていただいたが、カメラオフ&緊張していたのもあってうまくコミュニケーションがとれずもくもくしていた。次回からはカメラオンにしたり、チャットを使ったり、コミュニケーション取るようにがんばる
- 最近やっと質問できるようになってきたが、日報で質問するのが一番ハードルが低く、ついつい日報で個別に質問してしまっていて、オープンな場でできていない....。私が個別に解決できただけだとフリーライダーになってしまって申し訳ないので、これからDB設計を学ぶブートキャンプ生に向けて「今DB設計でつまづいたこと&どうやって理解したか」の記事もちょこちょこ書き進めている。が、これに加えて、Q&Aに投稿して自己回答したらもっといいかもしれないと思った。
- 振り返ると、休みの日よりも、仕事がある日の方が、時間が限られているという意識が働くせいか、学習に専念できている。休日の学習時間を増やしたい。一日全部自由時間にするよりも、勉強会やイベントがある方が時間にメリハリがつくので、気になったものに申し込んだ。
- 日報をその日のうちに出せてないことが多かった→次の日の朝に書くのは集中力がもったいないのでその日の夜に書くようにする。
- 記事作成にかかる時間の見通しが甘く、2倍以上かかった。説明するための例えのテーブルを作ったりすると時間がかかる。
- 自己参照/自己結合の理解ができなかった
- 画像のURL化がきちんとできているか確認すべきだった
- 朝6時台に起きても、寝るほど眠くはないけど眠い状態が続いているので改善したい。休日の昼寝が夜の睡眠に悪影響を及ぼしているのかも。
考えたこと
- 「自分の話した言葉が相手にちゃんと伝わっているか不安。自分の言語化能力がどの程度のレベルか知りたい」と一緒に輪読会をしてる方に話したら、「質問した時に自分が言語化できているかどうかは、自分が決めることでは?聞きたいことを知ることができて、分かりにくいと指摘されたわけでなければ、きちんと言語化できていると思う」と言われた。それを聞いて、たしかに自分が聞きたいことは自分にしか分からないことだな、と思った。
また、話を聞いてもらったことで、言語化能力の問題ではなくて自分が変なことを言ってないか・変に思われていないか不安という自信のなさから来ている問題ということに気づけた。
→ひとまず、質問した時は、聞きたいことを聞けて、疑問を解決できれば他のことは気にしないようにしようと思った。 - たまに日報が丁寧で分かりやすいと褒めていただくので、ブログというオープンな場でも文章を書いて役に立ちたいと思った。
- 雑談タイムで日報に気持ちを書いてくれるとメンターさんも嬉しいということがわかった。"本を読んだ"など、やったことだけを書かれると、簡単にできたのか?難しかったか?などが分からないのでありがたい&お気持ちを書くといろんな方がコメントくださって情報が集まることもあるとのこと。→引き続き書いていこうと思った。