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

フィヨルドブートキャンプ生。2021年中の卒業&就職を目指して学習中。

週報 4/5(月)~4/11(日)

週報 4/5(月)~4/11(日)

4/5(月)~4/11(日)の一週間の学習の振り返りをざっくり。 先週の3/29(月)~4/4(日)の週報を書いてないのでそちらもざっくり振り返る。

今週の学習時間

ラクティス外の学習・勉強会への参加は含めない。 目標達成🎉

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

先週

3/29(月)

やったこと

考えたこと

朝活した🌟必要なページはほぼ完成したと思う!

3/30(火)

やったこと

  • 昨日の日報提出
  • i18n課題の再提出
  • URLがusers/editの理由を知る。 →/users/:id/editだと、ログイン中のユーザが自分以外を編集しようとしていないか?をチェックする認可の処理が必要になる。実際のアプリケーションの自分のユーザーページのURLを見たら、current_user/editusers/settingsになっていた。なるほど〜

考えたこと

今日は早起きに失敗してしまったので、ほとんど学習できなかった。ずっと読みたいと思ってて一ヶ月ほど積ん読していた本を読み始めた💪 学習に集中できない時に少しずつ読み進めたい。

3/31(水)

やったこと

  • 画面遷移図の変更
  • ログインしたらユーザー一覧にリダイレクトさせたい→できず
  • ユーザー編集画面で更新した情報が、更新できてないことに気づいた→未解決のまま
  • ログイン前に/books に行けないようにする:before_actionを使う
  • 夜は友人と会う約束があったので学習せず。

考えたこと

  • やりたいことを都度検索して記事のコードをその場その場でコピペしても、その場しのぎの解決になっていて、自分が理解していないと意味がない&Qiita記事は前提がそれぞれ違うし間違っている可能性もあるので、やめる。
  • Railsの仕組みを分かってなさすぎる。今、Railsの仕組みがわかっていないのにdeviseを導入しているから、コードを書くときに、Railsのもともとの機能をつかえばいいのかdeviseを使えばいいのか分からず、混乱している状態。
  • 他の方の日報を見ていると、deviseあたりで、「Railsを全然分かってないので、書籍などで体系的に学んだほうがいいかも」と感じている方をチラホラ見かけたので、私もそうすることにした。
  • 教材が色々あって迷ったが、独習Railsがとても分かりやすいので一通り目を通すことにした。一回目を通すと、詰まったときにあそこに書いてあったな〜と思い出せるので、頭の中にインデックスを貼る方式で読もうと思う。が、devise課題に関係ありそうなところは自分のコード見つつしっかり読む。
  • 明日から独習Rails読む💪

4/1(木)

やったこと

  • 独習Railsを読む
    • 1章
      • 設定より規約
      • リソースフルルーティング
      • MVCモデル
    • 2章は実際にコードを書くときに読む
    • 3章途中まで
      • rails sしたら再びwebpackerのエラー

考えたこと

  • 私含めてみなさんが、「Railsはいろいろやってくれていて、どういう仕組みでこうなったか分からない」となるのは、この設定より規約という基本理念からきているのか〜なるほど。deviseも導入したらすぐにユーザー登録・ログイン/ログアウト機能・ユーザー編集ができてて、びっくりしてたけど、この理念からきていたのか。
  • プログラミング言語には、設定重視だったり、規約が多すぎたり色々な言語があるらしいが、webアプリを作るにあたって1から全部の設定を書くより、「どのwebアプリでもこの機能は使うよね」、というものがデフォルトでオンになっている方が、毎回同じ設定を1から書くより効率的でよさそうと思った。Railsが色々やってくれている仕様になっている理由が分かってちょっとスッキリ
  • 今日はたくさん寝たはずなのに学習中も眠くてあんまり集中できなかったのが辛かった。今週はそんな週だと割り切るようにする。

4/2(金)~5(月)

おやすみ😪

今週

4/6(火)

やったこと

  • 独習Rails:3章読む
  • モデルはデータベース自身のことではなく、データベースを便利に扱えるようにデータベースとやり取りする役割を持つ。 →モデル=DBと勘違いしていた。

考えたこと

  • 忘れかけていたscaffoldを思い出せた。初めてscaffoldを実行したときよりも深く理解できていると思う。
  • 2日の金曜から4日間学習していなかった💦元気が出てきたので今日からまたがんばる。「ちょっとずつでいいから毎日やる」を実行するのって結構難しい。
  • devise課題のコードの現況や残りのタスクがどうだったのか日にちがあいて、忘れかけているので進捗確認する。

4/7(水)

やったこと

  • 独習Rails3章で気になったことを調べた
    • before_actionとは
    • form_withヘルパー
      • form_withとform_forのちがい
      • deviseはform_forで書かれいるが、現場ではform_withに書き直しているのか? →メンターさんにコメントで教えていただいた。現場ではすぐに全部form_forをなくそうというほど急ぎで対応はしていないようだ。
  • たまった日報の提出

考えたこと

  • deviseのコードの意味がわかってきて嬉しい。
  • form_forを理解できた

4/8(木)

やったこと

  • 独習Rails3章
    • 部分テンプレート
      • renderメソッド
      • deviseの部分テンプレート
    • モデルに使えるメソッド
    • 「登録する」ボタンをクリックした時に裏側で何がおこっているか(時系列)
  • deviseについて調べた
    • deviseはデフォルトだとモデル,コントローラ,ビューが無い状態→カスタマイズしたければrails gで作成する
    • rails g devise User は何をしてるのか?
    • rails g devise:viewsrails g devise:views usersのちがい →READMEを読んでもよく分からず。 →メンターさんに、「後者を使うのはscoped viewというもので、管理者ユーザを別モデルのadminsにする場合などに、usersとadminsでそれぞれ別のviewを使いたかったりして、そういうとき使うというイメージ」と教えていただいた。

考えたこと

  • 今回の課題はモデルが一つなので、rails g devise:viewsの実行が正しいと分かった。Qiita記事など見ると、モデルが一つの場合でもrails g devise:views <モデル名>を実行している記事があり、どう使い分けたらいいか悩んでいたが、正しい情報をメンターさんに教えていただけてよかった。 なんとなくviews/users/の直下にdeviseのviewsもあった方がいいかなと思って、rails g devise:viewsを消してrails g devise:views usersを実行しなおそうとしていたので、実行する前にしれてよかった。
  • 私がdeviseで詰まっているメインの原因は、実装したいことをdeviseを使ってやればいいのか、Railsにもともと備わっている仕組みでやればいいのか分からないところだと思う。詰まったところを解決できそうなところはとくに重点的に読みたいので残りの要件とか課題を整理しようと思う。

4/9(金)

やったこと

考えたこと

  • deviseのカスタマイズ方法 https://github.com/heartcombo/devise/tree/master/app ここを見れば、deviseのコントローラやビューのコードが見れて、デフォルトの状態だとこのコードが参照される。 最初、 rails g devise:viewsやrails g devise:controllers を実行したらカスタマイズできることを知らなくて、deviseのコントローラやビューを探しても該当するコードがアプリケーションに無くて混乱した。 Railsの設定より規約の理念を知ってからこの仕様にしっくりきている。
  • READMEをがんばって読んだ!一次情報大事。 Qiita記事のコードを安易にコピペしない。

4/10(土)

やったこと

devise課題

  • deviseのコントローラをカスタマイズする
  • アプリの利用にはログインを必須にする
  • リダイレクト先を設定する
  • ユーザー情報を更新できない問題を解決
  • 更新時のリダイレクト先を自分のユーザー詳細画面にする
    • 書いたコードの意味を調べる
  • パスワードを忘れたらパスワード再設定メールを送信してパスワードを再設定できる
    • letter_opener_gem導入
  • i18n
    • devise-i18nのREADMEを読む
    • rails g devise:i18n:locale jadevise.views.ja.ymlを作成

考えたこと

  • 初めてdeviseを導入したときはコードの意味がわかってなかったが、今日はRailsの仕組みを理解した上で、READMEを見ながらコードの意味を理解して課題を進められた。成長を感じる💪
  • 詰まっていて後回しにしていたタスクを全部実装できた!うれしい🎉

考えたこと

  • 独習Rails読み勧めてから課題に戻ろうか迷ったが、意外とRailsへの理解が進んでいて、詰まっていたタスクを実装することができた。progateと独習Railsのおかげだ。嬉しい!成長を感じる😆

4/11(日)

やったこと

  • devise課題
    • i18n
    • Gitでの疑問
    • 提出🎉
  • 日報提出
    • 4/9(金)
    • 4/10(土)
    • 4/11(日)
  • 先週と今週の週報を書いた(この記事)

考えたこと

deviseの課題を提出できた🎉 この課題を通してRailsの仕組み、deviseの使い方への理解を深められたので嬉しい。

今週の振り返り

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

  • deviseの課題を提出できた🎉
  • Railsとdeviseの仕組みがわかってきた
  • devise,letter_opener_web,devise-i18nのREADMEを翻訳しながら読んだ
  • 遅延評価勉強法を実践できている。「全部理解してから始めたい病」を克服できている✨ 勉強が苦手な人向けの「遅延評価勉強法」 : けんすう日記 分からないことだらけの課題と向き合うよりも、教科書を順に読んでいくほうが、壁に当たることもなく、メンタル的にも楽だが、要件を実装するために情報収集している時が一番身になっていると感じるので、これからもこの方法を実践していく💪
  • 学習時間が目標を上回った。

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

来週の目標

  • devise課題の合格
  • omniauth課題
    所要時間の目安は12時間だが、この辺からRailsラクティスが難易度が上がるらしく、また独習Railsを読んでRailsを理解する必要がありそうなので、提出目標は、2週間後の4/25(日)にする。

週報 3/22(月)~3/28(日)

3/22(月)~3/28(日)の一週間の学習の振り返りをざっくり。

今週の目標&結果

今週の目標 結果
i18nの合格 修正中
kaminariの合格 再提出完了
deviseの課題 来週には提出できそう

今週の学習時間

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

日付 目標 実際
3/22(月) 2:00 4:15
3/23(火) 6:00 7:30
3/24(水) 2:00 2:15
3/25(木) 6:00 8:00
3/26(金) 2:00 3:30
3/27(土) 6:00 4:30
3/28(日) 6:00 4:15
合計 30:00 34:15

先週から再開した朝活のおかげで、目標時間を超えられた🎉

今週やったこと

3/22(月)

やったこと

  • devise #1
  • deviseの課題用のブランチを新しく切ってチェックアウト
  • Notionを使ってdeviseの要件の把握
  • WebアプリのDB利用の課題に合格をもらえたのでマージ
  • 週報書いた

3/23(火)

やったこと

考えたこと

  • 記事の通りに行ったらユーザー登録の機能はできたが、応用力が皆無。
  • ユーザーの一覧ページをどうやって作るのか?新しいページのルーティングの設定方法は?
  • 画面遷移図をつくって把握した方がいいと思った。
  • 郵便番号・住所・自己紹介はおそらくuserテーブルに追加するんだろうけど、どうやってやるんだろう。
  • アカウント登録のページと本棚のページがつながっていないからボタン作ってリンク貼るか、リダイレクトさせるようにせねば。
  • 色々メモしたが、何をやっているかいまいち分かっていない。Railsの教科書をもう一度読み直したほうがいいかも。
  • ファイルがどんどん増えるrails gコマンドを使うのがこわい。
  • Rails・deviseと仲良くなりたいので、もっとコードを書いて慣れていきたい💪

3/24(水)

やったこと

  • 23(火)の日報提出
    • 昨日のcodezineの記事の、コマンドやコードの意味を振り返った
  • devise #3

考えたこと

  • Railsが広大で、何も分からない状態だけれども、ユーザー認証機能を自力で作れるようになったらとても嬉しいので、急がば回れの精神でがんばりたい。

3/25(木)

やったこと

  • progate:Rails Ⅰ~Ⅱ途中
  • devise #4
    • 画面遷移図作成
    • rails g controller users indexでusersコントローラ作成
    • Usersモデルにカラム追加
    • railsでDBを確認する方法
    • rails db:migrateを無かったことにする方法

考えたこと

  • Userモデルにカラムを追加できたのと、画面遷移図を分かりやすくかけたのがよかった
  • Railsが何も分からなくて辛い...という気持ちになりかけているので、一番とっつきやすいprogateで学習することにした。
  • ページの作り方はわかったけど、ユーザー一覧ページと詳細ページを作成するために、どこにどうファイルを作ればいいか分からない。
  • 明日も引き続きprogateをやりながらdeviseを考える。画面遷移図を書いたことで、やるべきことが目に見えてクリーンになった✨
  • 疑問:/users というパスにユーザー一覧のページを作りたいのだけど、deviseですでに/users/~のページが作られている。 コントローラはdeviseだけど、パスは/users/~ がすでにある状態。この場合、deviseで作ったcontrollerをいじればいいのか 新しくrails g controller users indexでページを作るのか? →メンターさんから、「devise のcontrollerはそのdeviseの機能に専念させたほうがあとからツラくならない」と教えていただいたので、rails g contrller user indexでuserコントローラーを作ることにした。

3/26(金)

やったこと

  • devise #5
    • Userモデルにカラムを追加して、viewで表示する
    • formヘルパーを学ぶ
    • autofocus: trueautocomplete: "email"の意味を理解
    • アカウント登録画面でユーザー名なども入力できるようになった!

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

考えたこと

  • Userモデルに追加したカラムを、ユーザー登録画面に表示できた!目に見えると嬉しい。

3/27(土)

  • 日報提出
    • 25(木)
    • 26(金)
  • devise
    • deviseで作られた画面(ルーティング)の確認
    • ユーザー一覧画面/ユーザー詳細画面を作成:rails g controller Users index show
    • strongパラメーター設定
    • 既存のカラムに後から制約をつけたかったが、できず
    • バリデーション:登録時全部を入力必須にする

やったこと

  • devise #6
    • ユーザー一覧とユーザー詳細ページのルーティングができた!
    • deviseが用意してくれるルーティングの範囲と、自分で用意しなければいけないルーティングの範囲が分からず混乱していたが、わかってきた

考えたこと

  • 何が分からないか分からない状態は抜け出せたと思う。来週には提出したい。

3/28(日)

やったこと

  • devise #7
    • link_toで、ユーザー一覧から詳細画面にとべるようにする
    • ユーザー詳細画面の作成
    • マイページに編集リンク作る
    • kaminari実装
  • i18nの提出物にコメントする
  • kaminariの再提出

考えたこと

  • コントローラでUserモデルやBookモデルに対して使えるメソッドが分かってないから知りたい。new,find_by,allぐらいしか知らない。書籍をしっかり見たほうがよさそう。
  • どこのページにどのリンクを貼るかってユーザーの使い勝手において大事だろうな〜
  • ページができてきて嬉しい。
  • コミットの粒度こんな感じでいいのかな。コミットまとめられるらしいのでこまめにやってしまってる。

今週の振り返り

  • deviseがどんな機能を実装してくれるか、どんなルーティングを作ってくれるか分かった。
  • 月曜の時点で、Railsの知識は「Railsの教科書」を一周読んだ程度で、コントローラやモデルについては結構忘れていて、ビューしかちゃんと分かってない状態だった。その状態で火曜にdeviseを実装して、何も分からない状態だったが、progateをやりなが課題を進めたら、どこのファイルに何を書くべきかや、rails gコマンドが何をしてくれているかの理解が深まった。
    やっぱり、アウトプット駆動で教材をやった方が身につくなと思った。
  • 今週は出勤日全部、早起きしてカフェで2時間学習した!えらい😆

来週の目標

deviseの課題を来週中には提出したい。 - パスワード再設定をメールに送信する - ログインしたないとユーザー情報も本棚も見れないようにする - アプリケーションルートと、ログイン完了後のリダイレクト先を、ユーザー詳細ページにする

あたりで時間がかかりそうだな〜と思っている。i18n化はdevise-i18n-viewというgemをうまく使いこなせれば、そんなにかからなさそう。
だんだんRailsのことが分かってきて、「もっとRailsのことを知りたい!」というポジティブな気持ち。 次のomniauthの課題から難易度もグッと上がるらしいので、progateや独習Railsで基本をおさえていきたい。

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

3/15(月)~21(日) の一週間の学習の振り返り。

今週の目標&結果

今週の目標 結果
WebアプリからのDB利用の合格 ◎21(日)に合格
i18n の提出 ◎20(土)に提出
kaminari を使ったページング処理 ◎20(土)に提出
devise を使ってユーザー認証を実装する ✕ 来週から着手

今週の学習時間

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

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

今週やったこと

3/15(月)

やったこと

  • i18n:2日目
    • 用語理解:ロケール/国際化/localizationとは
    • デフォルトロケールの設定を、config/initializers/locale.rbconfig/application.rbのどちらに書けばいいかわからず。 →
    • I18n_generatorsを使って、ja.ymltranslate_ja.ymlを自動生成
    • 疑問点整理

考えたこと

  • 昨日はRailsガイドの説明がわからず、とにかく動くものを作るという感じだったが、i18nの使い方や書いたコードの意味がが少しずつわかってきた。
  • 久々に早起きして朝カフェで学習した!頭がスッキリしていて体も元気なので集中できた。温かくなってきて布団から出やすくなったので朝活がんばりたい。
  • 買った独習Railsi18nの項目があったので明日読む!
  • 公式ドキュメントの日本語が違和感があったり少し変なときは、原文を確認してみるとよいと学んだ

3/16(火)

やったこと

  • 独習railsi18nの部分を読む
  • Railsの教科書を読んで、モデルの復習

考えたこと

  • 翻訳ファイルが何をしているのかや、使い方・書き方がわかった
  • 独習Railsi18nの説明分かりやすい。いろんな記事を見て回るより一冊の本をじっくり読んだ方が効率的。
    翻訳ファイルが何をどこまで日本語化してくれるものなのかわからず大変だったが、独習Railsを読んだら体系的にi18n化のやり方が載っていて、説明もわかりやすくて本当に助かった。

3/17(水)

やったこと

  • 独習Railsを読みながらすべての日本語化を完了
  • activerecordを使った、翻訳ファイルtranslation_ja.ymlの書き方を学んだ

考えたこと

  • viewディレクトリ以外の、翻訳ファイルを当てるファイルを探すのが大変だったが、難関だったcreateボタンやflashメッセージも日本語化できた
  • 最初なんとなくで書いていたtメソッドの書き方を理解できたのが嬉しい。
  • Markdown形式のリンクを素早くコピーする方法を今日初めて知った。とても便利。
  • webアプリを使っていて出てくる英語はすべて日本語化できたので、明日はrubocopを通したり、提出前のチェックリストを確認して、提出する。

3/20(土)

やったこと

  • i18n
    • 提出前チェック:不要なファイルやコードを削除したり、rubocopを通したり。
    • 課題提出
  • kaminariの課題提出
  • webアプリのDB利用の修正点を整理
  • 16(火),17(水)の日報提出

考えたこと

  • i18nとkaminari、2つの課題を提出できた🎉
  • ja.ymltranslation_ja.ymlの使い分け方がぴんときていない。

3/21(日)

やったこと

  • DB利用の修正&提出→再度修正&提出して合格
  • 課題の修正
    • ブランチからREADMEを消さない
    • プルリクエストのタイトルをちゃんと書く
    • コミットの粒度をもっと小さくすべし
  • 20(土)の日報提出

考えたこと

  • WebアプリからのDB利用を合格した!RESTプラクティスがおわった🎉これでRailsラクティスに集中できる💪🔥

今週の振り返り

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

  • 振り返ってみると、つい一週間前までi18nを全然理解できていなかったことに驚き。初めてRailsガイドのi18nの説明を読んだ時に比べて、今はかなり理解が進んだと思う。
  • 今週から朝活を再開した。仕事がある日4日中、3日早起きして職場近くのカフェで朝2時間学習した。温かくなってきたので、早起きがんばりたい🌅
  • 課題の進捗もいい感じ。ただ、deviseの課題が重そうなので、不安。

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

  • 今週はとくに思い当たらない。体調もかなり良好で、集中して課題に取り組めた。

来週の目標

目標 目安時間
i18nの合格 -
kaminariの合格 -
deviseの課題 14:00

近況 & 来週の目標

3/1(月)から体調が悪くなり、それに伴ってメンタルも沈んでしまっていて学習から遠のいていたので、日報も週報も書いていなかった。
回復したので、今日から学習再開🔥。およそ2週間ぶり。
気がついたら3月が半分終わってビックリしている。

今の気持ち

  • 体調が悪い時に取り組んでいた課題を、今日やってみたらそこまで難しく感じなかった。まだRubyのコードを読むのに慣れていないので、疲れている時や仕事後はより難易度が高くなってしまうんだと思う。
  • 長時間詰まっていた課題を次の日に取り組んだら大したことじゃなかった、ということがこれまで何度もあったので、難しいと思ってもあんまり気落ちしないようにしようと思った。
  • 久々に学習したら、やっぱり楽しかったので、がんばって卒業するぞ〜という気持ち💪
  • 2週間休んでいたことに対して後悔はそんなに無いのだが、
    • 休む時間が長引くほど再開が億劫になる問題(本当は今週木曜あたりから元気だった)
    • 体は休んでいたが、学習していないことへの罪悪感を感じてしまい、心は休めていない問題
      をなんとかしたいな〜と思っている。

来週の目標

目標 目安時間
WebアプリからのDB利用の合格 -
i18n の提出 9:00
kaminari を使ったページング処理 4:00
devise を使ってユーザー認証を実装する 14:00
(この辺からググる程度では実装できなさそうな予感)

あたたかくなってきたので、朝活も再開したいな〜と思っている。

週報 2/22(月)~2/28(日)

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

今週の目標&結果

今週の目標 結果
TwitterのDB設計をどうやって行ったかまとめる 日報に詳細書いてあるので、やめた
DB設計:他の受講生の提出物をチェック
自己参照/自己結合の理解
【ブログ】DB設計で学んだこと&詰まった点
【ブログ】web技術の基本で学んだこと
【ブログ】webを支える技術で学んだこと
【ブログ】URL設計について学んだこと
【ブログ】Gitで課題提出するまでの手順
【ブログ】TeamGeekを輪読会の感想 着手もできず
2月の振り返り&計画の見直し
(できれば)Railsの教科書の6~8章(最後) 6と8は完了/
残り7章
(できれば)book_appをリモートリポジトリのmainブランチにpushする

今週の学習時間

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

日付 目標 実際
2/22(月) 2:00 0:00
2/23(火)祝日 6:00 0:45
2/24(水) 2:00 2:00
2/25(木)休み 6:00 4:15
2/26(金) 2:00 0:00
2/27(土) 6:00 7:30
2/28(日) 6:00 8:15
合計 30:00 22:45

今週やったこと

2/22(月

やったこと

  • 学習せず。

考えたこと

  • 入浴した後、自室で学習していたのだが、眠すぎて週報を書くことすらできなかった。お風呂に入ると体が一気に睡眠モードになってしまう😴
  • 復習が疎かになっているので、Railsに本格的に入る前に、今週はDB設計,RESTの復習に注力する予定。

2/23(火)祝日

やったこと

考えたこと

  • 週報を書いた後、復習をかねてブログを書こうとしたら、少し疲れていてなかなか集中できず、せっかくコワーキングスペースに行ったのに帰ってしまった。
    いつもはコワーキングスペースに行くとスッと集中モードに入れるので、うまく睡眠が取れなかったのかなと思った。

2/24(水)

やったこと

  • Railsの教科書(5~6,8章)
    • 5章(p.91-95):scaffoldで作った既存のテーブルに、あとからカラムを追加する
    • 6章:awesome_printをインストールしたが使えず。どうやらRubyのバージョンが原因のよう。bundlerの理解を深めた。
    • 8章:あとがき

考えたこと

  • 5-6章,8章を読み終わった!残るは7章!
  • Ruby3.0.0でawesome_printが使えない問題は、バージョン1.9.0で解決されている。時間があるときに試す。
  • bundlerの仕組みがよく分からずモヤモヤしていたが、「Bundlerは、GemfileとGemfile.lockで互換性の管理をしつつ、bundle updateで新しいバージョンもインストールして使えるから、便利だよ!」ということが分かった💡Ruby超入門10-1にも記述があるので、読み返す。

2/25(木)

やったこと

考えたこと

  • DB設計は、色んなところで理解につまづき、世界観?を理解するのが難しかったので、これから学ぶ方の助けになればいいなという気持ちで書いた。
  • Gitの記事は、フィヨルド生で参考になったと仰ってくださる方がいて嬉しかった!

2/26(金)

やったこと

  • 学習せず。

考えたこと

  • 早起きに失敗して出勤前に学習できず&仕事後疲れて学習できなかった。

2/27(土)

やったこと

考えたこと

  • ずっと後回しにしていた、去年秋に読み終わった『Web技術の基本』を読んで学んだこと・疑問に思って調べたこと・感想を書けた。
  • ブログが思ったより、書くのに時間がかかった💦久々に本の内容を復習して、それを自分なりに言葉で説明してまとめたので、良い復習になった。
  • 伊藤さんの記事:ブログに技術書の内容を丸写しする問題点と、オリジナルなコンテンツを書くためのアイデアを参考にしながら、記事の内容が無断転載にならないように、気をつけて書いたが、大丈夫か少し心配😅もしご指摘があったらすぐに修正or削除するつもり。

2/28(日)

やったこと

考えたこと

  • ずっと書こうと思って後回しにしていた記事を2本も書けた!

今週の振り返り

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

  • 今週はブログでたくさんアウトプットできた!週報をのぞいて記事5本書いた。がんばった〜💪
  • 気づけば今年から始めた週報を2ヶ月連続で書けている。書かないと気持ち悪くなるくらい習慣化できている✨
  • 最近休みの日は無理やり早起きせず、ぐっすり眠ることを重視している。アラームも休みの日はつけないことにした。
    無理やり早起きしても後でエネルギー切れを起こしてしまうので、8時台まで寝るのは許容範囲にしている。

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

  • 火曜の祝日にもう少し学習できたらよかったな〜と思う。でも、毎日元気全開で学習するのは難しいので、反省はしても責めないようにする。 やる気と健康にはムラがあるもの!

来週の目標

合計23:00分

  • WebアプリからのDB利用(5:00) ※レビューに時間かかるので最優先
    • 残り:prepared statementを使った実装。
    • GitHubへプルリクエストで提出
    • 合格したい!
  • Railsの教科書の7章(1:30)
  • Railsi18n を理解する (9:30)
  • kaminari を使ってページング処理を実装する (4:00)
  • 【ブログ】TeamGeekを輪読会の感想 (3:00)

『Webを支える技術』を読んで学んだこと

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

フィヨルドブートキャンプの課題である、「Webを支える技術 -HTTP、URI、HTML、そしてREST」(以下、「Webを支える技術」)」を、techplay女子部で輪読会をして読み終わったので、REST,URI,HTTPを中心に学んだこと・感想を書いた。

<<無断転載にならないよう気をつけて書いたつもりですが、もしご指摘等ありましたら修正あるいは削除させていただくつもりです>>

活動内容

  • 期間:11/15(日)〜12/24(木)
  • 人数:2人→途中から3人
  • ツール:zoom / HackMD
  • 時間帯:毎朝6:00~7:00 (起きられなかったら無し)
  • 形式:予習なしで、その場で読む。10分各自で読む&疑問や感想をHackMDに書く、次の10分で話し合い。これを3回繰り返して1時間。

本の構成

  • 第1部 Web概論
    • 第1章 Webとは何か
    • 第2章 Webの歴史
    • 第3章 REST
  • 第2部 URI
    • 第4章 URIの仕様
    • 第5章 URIの設計
  • 第3部
  • 第4部 ハイパーメディアフォーマット
  • 第5部

REST

アーキテクチャースタイルとは

RESTはクライアント/サーバーから派生したアーキテクチャースタイル

下記の文章の意味が理解できなかったので整理した。

実はRESTは、クライアント/サーバから派生したアーキテクチャスタイルなのです。素のクライアント/サーバアーキテクチャスタイルにいくつかの制約を加えていくと、RESTというアーキテクチャスタイルになります。
(山本陽平 著 『Webを支える技術 -HTTP、URI、HTML、そしてREST』 p.26 より引用)

クライアント/サーバとは

  • アーキテクチャスタイルは、REST以外にも存在し、クライアント/サーバはその一つ
  • クライアント/サーバー:クライアントとサーバがHTTPというプロトコルで通信して、クライアントはサーバにリクエストを送り、サーバはそれに対してレスポンスを返してあげる方式
  • 単一のコンピュータ上ですべてを処理するのではなく、クライアントとサーバに分離して処理できることが利点。
  • RESTはこれに制約を加えたもの

制約とは

制約とは、以下の5つのアーキテクチャスタイルを指す。

  1. ステートレスサーバ

    • サーバー側で状態をもたない(リクエストする度毎回クライアントのことを忘れている/はじめまして)
    • HTTPをステートフルにするcookieはRESTの観点からすると、誤った拡張。しかし使わないわけにもいかないのが現状なので、必要最低限に使う。

  2. キャッシュ

    • 一度取得したリソースをクライアント側で使いまわす方式。
      例:「戻る」をクリックすると初めて接続したときより早い

  3. 統一インターフェース

    • インターフェースとは:プログラム同士の接点
    • 統一インターフェースとは:URLで示したリソースに対する操作を、統一した限定的なインターフェースで行う事。
    • メリット:インターフェースが統一されている事で、Webを利用しているシステムは同じHTTPメソッドで接続ができる。制限を加えることで、アーキテクチャをシンプルにできる。

  4. 階層化システム

  5. コードオンデマンド

    • プログラムコードをサーバからダウンロードし、クライアント側でそれを実行する
      例:JavaScript

結論

  • クライアント/サーバーというアーキテクチャスタイルに、この5つのアーキテクチャスタイル(制約)を加えたものがRESTである。
  • 実際にRESTに基づいて設計する時は、現実的にすべてのアーキテクチャスタイルを取り入れることができないこともあるため、いくつかを除外してもいい。

リソースとは

URI(URL)

クールなURIは変わらない

ブックマークに登録してあったお気に入りのWebサイトがある日突然見えなくなる、苦労して作成したリンク集が1年後には半分以上リンク切れ、検索エンジンの検索結果に出てくるページが見つからない
(山本陽平 著 『Webを支える技術 -HTTP、URI、HTML、そしてREST』 p.53より引用)

  • なんと、1990年代後半までは、URIが変更になることは日常茶飯事だった。=Webの根幹を揺るがす問題
  • Webはそれぞれのリソースにほかのリソースへのリンクが埋め込まれたハイパーメディアシステムなのに、リンクが切れてしまうということは、ハイパーメディアシステムが機能しないことになる。
  • Webの発明者ティム・バーナーズ=リーはこの状況を憂い、1998年に「Cool URIs don't change」(クールなURIは変わらない)」を発表した。

  • 自分が生まれたのが1995年なので、その頃にURLが変わっていてせっかくブクマ登録しても404になってしまう、という事態が信じられない...。

URIを変えないようにするための設計指針

 1. URIにプログラミング言語依存の拡張子を利用しない(.pl、.rb、.do、.jspなど)
 2. URIに実装依存のパス名を利用しない(cgibin、servletなど)
 3. URIにプログラミング言語のメソッド名を利用しない
 4. URIにセッションIDを含めない
 5. URIはそのリソースを表現する名詞である

(山本陽平 著 『Webを支える技術 -HTTP、URI、HTML、そしてREST』 p.57 より引用)

指針について補足

  • 3.のメソッド名 = プログラミング言語のメソッドのことを言っている。(例)RubyのArrayクラスのsizeメソッド
  • CGIは廃れている
    Web技術の基本で学んだCGIが、この本では廃れた技術と書かれていた。2010年に発売した本なので2020年現在だと更に使われなくなっていそう。

    リクエストのたびにプロセスを起動するCGI方式は性能面で難点があったため、そのほかの手法に取って代わられました
    (山本陽平 著 『Webを支える技術 -HTTP、URI、HTML、そしてREST』 p.55より引用)

  • 4.のセッションIDが何かについては以下の記事で説明。

シンプルなURLは、ユーザーの使い勝手も良くする

  • シンプルだとその分文字数が少ないので、ユーザーが覚えやすい
  • 上記の1~5に該当しないURLは、ユーザーには馴染みがない

→文字数は少なく&シンプルにしよう。

階層で管理できない情報を表現したい時

  • 階層で管理できない情報を表現したいとき、例えばGoogleマップの位置情報を表現したいときは、マトリクスURIを使う。

地図中のある特定の場所を表現するURIには、緯度と経度のほかにも表示スケール(縮小・拡大)や地図か航空写真かのフラグなど、複数のパラメータが必要になります。しかもこれらのパラメータはそれぞれ独立した軸を持つため、個々のリソースを階層構造で表現できません。
(山本陽平 著 『Webを支える技術 -HTTP、URI、HTML、そしてREST』 p.62より引用)

  • マトリクスURIは、複数のパラメ−タをセミコロン;で区切ってリソースを表現する。
http://hello.jp/map/lat=35.154328;lng=159.462784

URIが重要な理由

  • URIはリソースの名前である
  • URIは寿命が長い
  • URIはブラウザがアドレス欄に表示する

HTTP

HTTPのバージョン

アプリケーション状態とは

  • アプリケーション状態 = セッション状態
  • セッションとは:あるWebサイトにアクセス(あるいはWebシステムにログイン)して、ログアウトするかブラウザを閉じるまでが1セッション。1セッションで1ページしか閲覧しない場合もあれば、1セッションで何ページも見る場合もある。
  • セッション状態とは: 一連の操作の間の状態のこと。例:「ハンバーガーセットをポテトで注文している」という情報のこと。

HTTPメソッド

べき等性と安全性

  • べき等性:ある操作を何回行っても結果が同じであること。
  • 安全性:操作対象のリソースの状態を変化させないこと。 ※セキュリティ的な意味合いではないので注意。

→Webアプリを開発する時にこの2つがどう関わってくるのかイメージが湧かないので、今は「べき等性と安全性という性質がある」ということを覚えておく。

メソッドの間違った使い方

  • WebサービスやWebAPIの設計を誤ると、これらのメソッドが安全でなくなったり、べき等でなくなったりする
  • 例えば、GETの目的はリソースを取得することなのに、GETでリソースを更新したり、リソースを削除したりしてはダメ。
  • POSTは他のメソッドではできないことを色々できるが、他のメソッドでできることをPOSTにやらせてはいけない。
    特にGET,PUT,DELETEでできることをPOSTで行うとべき等性と安全性が損なわれる。
  • DELETEがべき等でなくなる例
    • /latestというURLがあり、「最新バージョンのリソース」を示すものだとする。
    • これをDELETEメソッドで削除すると、
    • 1回目:最新バージョンを消す
    • 2回目:1回目で消したバージョンの次に新しいバージョンを消す
    • 3回目:2回目で消したバージョンの次に新しいバージョンを消す...というようにエンドレスでバージョンを削除してしまう。

ステータスコード

ステータスコードの分類と意味

分類 意味
1xx 処理中
2xx 成功
3xx 他のリソースへリダイレクト
4xx クライアントエラー
5xx サーバエラー

ステータスコードは、クライアントとサーバーを疎結合にするための工夫

下記の文章の意味が理解できなかったので調べた。

ステータスコードを先頭の数字で分類するのは、クライアントとサーバの約束事を最小限に抑えて、クライアントとサーバの結び付きをなるべく緩やかにする、すなわち疎結合にするための工夫です。一般的に、システムが疎結合になると、コンポーネント間の独立性が高まり、コンポーネントの置き換えや拡張が容易になる、と言われています。HTTPで言えば、コンポーネントとはサーバとクライアントのことです。つまり、サーバのバージョンアップやクライアントの置き換えが行いやすい、ということです。
(山本陽平 著 『Webを支える技術 -HTTP、URI、HTML、そしてREST』 p.113より引用)

疎結合とは

  • 疎結合と密結合という2つの概念がある。どちらも結合度(結びつきの強さ)を表す用語。コードでもこの2つの考え方がある。
  • 密結合
    • 処理を同一タイミングで行う場合に互いの処理同士の干渉が大きいもの。
    • コード同士が複雑に絡み合っている状態なので、長期的な保守を考えるのであればやめた方が良い。
  • 疎結合
    • 一緒に実現するコードが互いの干渉がなく一つ一つのクラス独立しているもの。
    • 将来的な拡張に柔軟に対応できて良い。

コンポーネントとは

  • 機器やソフトウェア、システムの構成する部品や要素。

結論

  • 本では「ステータスコードは、クライアントとサーバーを疎結合にするための工夫」と言っている。
    →たしかに、400番台だとクライアント側に原因があるエラー、500番台だとサーバー側に原因があるエラーというように、原因の所在がきっちりと分かれている
  • サーバーとクライアントが密結合だと、一方の何かを変えたい時にもう片方にも影響が出て処理が複雑そうだと思った。お互い独立している=疎結合である方が良い、ということだと解釈した。

ステータスコードは正しく割り当てる

  • Webサービス/WebAPIを開発するときに、ステータスコードを正しく割り当てないと、ブラウザ(クライアント)が間違った処理をしてしまうので、正しく割り当てることは最低限のマナー。
  • 例えば、本当は404 Not Found(リソースの不在)=エラーの状態なのに、404を返さず200 OK(リクエスト成功)を返す仕様にしているとする。
    これでは検索エンジンのロボットが404の状態をエラーでなく、正式なリソースと判断してしまう。
  • 開発しているWebサービスやWebAPIでエラーが起きたときに、どのステータスコードを返すかは、とても重要な設計の検討事項。とくに400番台は種類が多いので注意。

HTTPヘッダ

コンテントネゴシエーションとは

メディアタイプや文字エンコーディング、言語タグは、サーバが一方的に決定するだけではなく、クライアントと交渉(ネゴシエーション)して決めることもできます。この手法を「コンテントネゴシエーション」(ContentNegotiation)と呼びます。
(山本陽平 著 『Webを支える技術 -HTTP、URI、HTML、そしてREST』 p.132より引用)

自分の言葉で説明してみた。

  • 英語と日本語の両方に対応しているサーバーに、日本語しか受け付けないリクエストをクライアントが送ると、日本語が返ってくる。
  • クライアント「日本語しか対応してないから日本語でよろしく」
  • サーバー「OK、日本語で返すね」

このやり取りのことを「交渉」と言っている。

キャッシュ用ヘッダ

  • HTTPの機能の一つ:キャッシュは、キャッシュ用ヘッダによって使える。
  • あるリソースがキャッシュ可能かどうかは、そのリソースを取得したときのヘッダで判断する。リソースがキャッシュ可能かどうか、その有効期限がいつまでなのかは、Pragma,Expires,CacheControlヘッダを用いてサーバが決める。

no-cashe=キャッシュ禁止ではない

  • 「キャッシュを使うな」という意味ではない。
  • 一度キャッシュに記録されたコンテンツは、現在でも有効か否かを本来のWebサーバに問い合わせて、確認がとれない限り再利用してはならない、という意味。

条件付きGET

以下の文章の理解が難しかったので、自分の言葉でまとめた。

クライアントがExpiresやCacheControlヘッダを検証した結果、ローカルキャッシュをそのまま再利用できないと判断した場合でも、条件付きGETを送信すればキャッシュを再利用できる可能性があります。条件付きGETは、サーバ側にあるリソースが、クライアントローカルのキャッシュから変更されているかどうかを調べるヒントをリクエストヘッダに含めることで、キャッシュがそのまま使えるかどうかを検証するしくみです。
(山本陽平 著 『Webを支える技術 -HTTP、URI、HTML、そしてREST』 p.146より引用)

  • クライアントが自分のローカルストレージに保存しているキャッシュを再利用したいので、ExpiresやCacheControlヘッダを検証したら、no-casheだったので、サーバーがリソースのキャッシュを禁止=再度サーバーにアクセスしなくてはいけないことが分かる
  • no-casheと返されていても、「条件付きGET」を送信することで、自分のキャッシュが使えるかどうか調べることができる
  • 調べ方=サーバ側にあるリソースが、クライアントローカルのキャッシュから変更されているかどうかを調べるヒントを、リクエストヘッダに含める。
  • 調べ方には2つある。
    • If-Modified-Since (要求)ヘッダ
    • If-None-Match (要求)ヘッダ

HTML

rel属性

  • rel属性とは:リンク元のリソースとリンク先のリソースがどのような関係にあるか。
  • HTMLを書く時、意味を分かっていないで、rel="stylesheet"と書いていた。これは「元のHTMLリソースを外部のCSSリソースにリンクするとき」に書く。
  • stylesheet以外にも色んな例がある。

リソース設計

リソース設計の手順

  1. Webサービスで提供するデータを特定する
  2. データをリソースに分けるそして、各リソースに対して次の作業を行います。
  3. リソースにURIで名前を付ける
  4. クライアントに提供するリソースの表現を設計する
  5. リンクとフォームを利用してリソース同士を結び付ける
  6. イベントの標準的なコースを検討する
  7. エラーについて検討する

  8. リソース設計の最初の工程は、サービスで提供するデータを理解し特定する作業。

  9. 自分のサービスでどのようなデータを提供するのかを理解していなければ、リソースは設計できない。
  10. 日本郵便が提供してるCSVのデータ
    →会社で使ってるシステムが、郵便番号を入れても住所が自動で入力されないので、これを使って実装できそう

  11. 機能の結果をリソースとしてとらえることが、重要

クエリパラメータ

標準的な利用コースを検討する

  • 利用コースという言い回しが難しく感じる。
  • つまり、このWebサービスをクライアントがどんな目的をもって、何を知りたくて使うかを想定して、どういうリソースのたどり方(=利用コース)をするか
  • 今回は、郵便番号を入力して目的の郵便番号リソースを取得するコース(この郵便番号てどこの市町村だろう?)/住所を入力して郵便番号リソースを取得するコース/地域リソースの階層をたどりながら郵便番号を選択するコース
  • 利用する人の立場に立って考えなければいけない。

全体の感想

  • 『Web技術の基本』を先に読んでよかった。初めて読んだ時は、知らない用語ばかりでちんぷんかんぷんだったが、2回目は、アーキテクチャースタイル、REST,URI,HTTPの基本的な知識、リクエストとレスポンスの裏側で何が起こっているか、リクエストメッセージの構成、を事前に理解していたため、理解することができた。
  • メンターさんから、Ruby on Railsを触った後や、就職した後に読んでみると、 理解度が変わってくると伺ったので、今回はREST,URI,HTTPの理解を優先し、それ以外は、実務で使うことになったらまた戻ってこようという気持ちでサラッと読んだ。
  • 触ったことがある技術とない技術で、読んだときの理解度が全然ちがうなと思った。
  • 輪読会についての感想は以下にまとめた。 saki-htr.hatenablog.com

参考書籍・記事

URL設計について学んだこと

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

フィヨルドブートキャンプの「TwitterのURLを設計する」という課題を合格したので、URL設計について学んだことをまとめた。

URL設計とは

1. リソースにどんな名前をつけるか(どんなURLにするのか)
2. 決めたURLに対して、どのHTTPメソッドを使うか

を決めること。

Method Path Description
GET /foo fooの一覧を表示。
POST /foo fooを受け取って追加する。
DELETE /foo/123 fooのidを受け取って削除する。
GET /bar barの一覧を表示。

URL設計について書く前に、リソース,URL,HTTPメソッドについて説明する。

URLとは、リソースに名前を付けたもの

リソースとは

  • Web上に存在する、名前をもったありとあらゆる情報
  • URLと聞くと、Webページのアドレスを思い浮かべがちだが、他にも色々ある。
    例えば、Web上にある、

    • 写真
    • 文献・論文
    • 自分が登録したブックマーク
      なども全てリソースである。
  • リソースは、人の名前などと違って必ず一意の名前(その情報だけを指す名前)でなければならない。

URLとは

  • リソースに名前をつけたもの。
  • URLの基本的な仕様:uriスキーム/ホスト名/パス。もっと複雑な仕様もある。
  • TwitterのURL設計の課題では、このパスの部分を設計した。
  • ホスト名が一意であること & URLがそのWebサービスの中で一意になるように設計することで、リソースは世界で一意になっている。

HTTPメソッドとは

  • WebブラウザからWebサーバに対してのお願い。
  • 正式名称:HTTPリクエストメソッド

リクエストのどこに当たるのか

f:id:Saki-Htr:20210228094934p:plain (HTTP入門 - とほほのWWW入門 より引用)

  • リクエストは以下の3つの部品から構成されている。
    1. リクエストライン
    2. リクエストヘッダ
    3. リクエストメッセージボディ

  • この2. リクエストヘッダの中にHTTPメソッドが含まれている。
    メソッド パス名 HTTP/バージョン

HTTPメソッド一覧

  • お願いには色んな種類がある。
メソッド 何をするか
GET リソースの取得
POST 子リソースの作成、リソースへのデータ追加、その他処理
PUT リソースの全部更新、リソースの作成
PATCH リソースの部分更新
DELETE リソースの削除
HEAD リソースのヘッダ (メタデータ)の取得
OPTIONS リソースがサポートしているメソッドの取得
TRACE プロキシ動作の確認
CONNECT プロキシ動作のトンネル接続への変更

※ LINK / UNLINK は、HTTP/1.1 ~廃止された。

POSTとPUTの違いは、URIの決定権

  • POST
    • サーバー側が決める
  • PUT
    • クライアント側が決める。
    • リソース名をクライアント側が指定して作成or更新をかけるメソッド。
    • 新規作成も更新も同じ書き方。
      例えば、PUT /articles/3421は新規作成かもしれないし、更新かもしれない。
      →リクエストされた時に、既存のリソースだったら更新し、新しいURLだったら新規作成する動作を行う。
    • 例:Wikipediascrapboxは、ユーザーが付けた記事のタイトルがそのままURLになっている。

f:id:Saki-Htr:20210228095645p:plain (鬼滅の刃 - Wikipediaより引用)

  • Twitterの設計では、クライアント側がURLを決める必要性を感じなかったため、PUTを使った。

PUTは全部更新、PATCHは部分更新

PATCHメソッドは『Webを支える技術』には載っていなかったので、PUTとの違いを調べた。

  • PUTメソッド

    • べき等である
    • リソースの全部を更新
      ブログの記事に例えると、記事の内容を全部変えるのがPUT。
  • PATCHメソッド

    • べき等でない
    • リソースの一部分を更新
      ブログの記事に例えると、記事の台頭だけを変えるのがPATCH。
  • リソースの一部更新をする場合には、そのリソース (URL)へPATCHリクエストを投げるのが、最も自然な設計。
  • PATCHはべき等が必ずしも保証されていないメソッドのため、PUTとDELETEを組み合わせた設計のほうが、シンプルでねき等性のある設計になることもある。

  • Twitterの設計では、リソースを部分的に更新するような機能の設計はしなかったので、PATCHメソッドは使わなかった。

URL設計で気をつけること

  • パスのネストは最小限に抑える
  • 名詞を使う
  • ホスト名がこの世に一意であることと、URLが一意であることで、リソースは世界で一意となる。なので、URLを設計する時は、一意を示す設計をしなくてはいけない。
  • メソッドとパスの掛け合わせが重複しないようにする

メソッドとパスの掛け合わせが重複しないようにする

最初、以下のように提出した(一部抜粋)

Method Path Description
GET /user_id ユーザーを表示する
GET /tweet_id ツイートを表示する

レビューで以下のようにご指摘をいただいた。

  • このuser_id, tweet_idには、シンプルに考えると数字が入ってくる。
  • ユーザーのプロフィール画面を表示するURLと特定のツイートを表示するURLは別物だが、数字を入れてみると、URLとメソッドの掛け合わせが重複してしまうことが分かる。
Method Path Description 数字入り想定Path
GET /user_id ユーザーを表示する /128
GET /tweet_id ツイートを表示する /128
  • この設計は一見、/user_id/tweet_idで区別できているように見えるが、リクエストを処理するサーバにとってはまったく同じものに見えて区別ができない。
  • この問題を解決するために、サーバーがどのテーブル(リソース)を参照すれば良いか把握できるようにしてあげる必要がある。

このため、最終的に以下の設計にした。

Method Path Description
GET /users/:user_id ユーザーを表示する
GET /tweets/:tweet_id 特定のツイートを表示する

これなら、idの部分が重複しても、

  • /users/123
  • /tweets/123

となり、区別できる。

感想

  • 最初、Twitterの何がリソースに当たるか分からず、混乱した。
  • ツイートの新規作成画面を取得するリクエストと、ツイートを行うリクエストは、ブートキャンプの日報作成時のURLを参考にさせていただいた。
  • URL設計は、Sinatraのメモアプリ作成課題でも行うので、大事。
  • 設計はコードを書く時と同じで正解が一つでないので、
    課題修正時に、「なぜその設計にしようと思ったか?」を述べるようにしたら、メンターさんから、以下のように仰っていただけたのが嬉しかった🥰
    • 理由を述べることができるというのはとても大事な能力
    • ぜひ今後も「どうしてこういう設計/実装になったの?」と聞かれた時に答えられる姿勢で進めてほしい

参考書籍・記事