はじめに
現在参加しているFJORD BOOT CAMP。そのRuby on Railsのプラクティスの初歩、「Railsのi18nを理解する」を今日クリアすることができました😆
そこで、このプラクティスで学んだことをまとめたいと思います💪
作成したもの
このプラクティスで学んだこと
i18nの基本
i18nとは、「internationalization」(国際化)のことで、アプリを地域に囚われず、どこでも誰でも使えるようにしようという考え方です。internationalizationがi〜nまで18文字あるということから、そのように呼ばれているようです。
大雑把に説明すると以下のような手順で実装することができます。
- 訳文ファイルを用意する
- デフォルトのlocaleを変更する
- URLを元にロケールを設定できるようにする
- アプリ内で使用されている言語を多言語で表示できるようにする
Rails guideを参考に、手を動かしていき、なんとか実装することができました😆
Git・Githubの実践的な使い方
今回のプラクティスではここが1番の難所だったように思えます💦 以下に、直面した問題をまとめてみました。
コミットの粒度が分からない問題
まずは、この問題にぶち当たりました💦 「どこから、どこまでをコミットに含めて良いのか😭、もはや一つのコミットにした方が良いのか🤔」
これに関しては現在も自分の中で、明確な基準があるわけではないのですが、以下のサイトを参考にさせていただきました。 特に自分が重要視しているのは、「最小の意味でコミットする」ことです💪
【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた - Qiita
(再演)きれいなcommit, pull requestを知りたい/作りたい方のためのgit勉強会 - Speaker Deck
コミットログがどんどん汚くなっていく問題
上記のようにコミットには注意していたんですが、それでも未熟なため意味が成立していない無意味なコミットをしてしまったり、コミットメッセージ が同じコミットをしてしまうことがありました💦
この問題を解決してくれたのが、
git rebase -iとgit push --force-with-leaseコマンドでした。
git rebase -iでコミットログを編集して、git push --force-with-leaseでローカルの変更をリモートに比較的安全に反映させられます。
最初はgit rebase -iの使い方も覚束なかったのですが、今はある程度は使えるようになってきました‼️
File changeの確認漏れ問題
PRを出した後に、File changeの画面をチェックすることで、テキストエディタ上では気づかなかった問題点に気づくことができるわけなのですが、File change画面を確認したつもりでも、どんどんとメンターの方から修正点が出てきました💦
原因としては、File changeを漠然と確認していたことだと思います💦
レビューしていただくの方の負担を減らすためにもFile changeで間違いに気づくことは大切なことだと痛感しました。メンターの方から、今後はFile change画面を確認する時のポイントを教えていただいたので、そのポイントに気をつけてチェックをしていきたいところです💪
「Railsにお任せ」ではいけないということ
コードレビューを受けて、自分は本当に「Railsにお任せ」状態だったのだと思いました。 自動生成されるコードの意味をあまりよく分からず、そのままにしており、そのままではいけないのだと痛感しました💦
「このコードはなんで存在しているのか」ということを問いかけて、分からなかったら調べるということを繰り返して、今後のプラクティスに望んでいきたいです💪
最後に
実践的な内容に取り組む度に、自分のできなさを実感してしまいますが、コツコツ地道にを忘れずに就職目指して頑張っていきたいと思います💪
参考にさせていただいたサイト等
【初心者向け】「コミットの粒度がわからない問題」の模範解答を考えてみた - Qiita
(再演)きれいなcommit, pull requestを知りたい/作りたい方のためのgit勉強会 - Speaker Deck