komagataのブログSearchkomagataのブログHomerails初心者がRailsプロジェクトへの初PRする前に見るチェックリストフィヨルドブートキャンプというプログラミングスクールで初めてのPRに対するレビューをたくさんやっています。これらの指摘は世界中で行われていると思うので無駄が減るように書きました。changedを確認したか真っ先に注意したい点。changedを必ず確認する癖をつけよう。GitHubのソースコードビューワーの機能で色々と気づける点もある。changedを一回も見てないなというPRはわかるので職場の先輩に怒られる。lintを通しているかrubyだったらrubocop、jsだったらeslintどういうルールが良いかという高度は話題は置いておいて、まずはlintを通しているか否か。ファイルの末尾に改行が無いかこれどのエディターでも設定で自動的に入るようにできるので設定すること。同じコミットログが続いていないか適切な文章などの高度な話題以前に明らかに適当になっている場合がある。コミットログというのはちゃんと見られるものだということを理解しよう。コミットログが英語/日本語になってないかプロジェクトのルールに合わせましょう。フィヨルドブートキャンプでは統一されていればどちらでもいいです。コミットログが雑になってないかmodifyだけ。追加だけは後から見た人が困るので駄目。困る人には1ヶ月後の自分も含まれる。コミットしたユーザーアイコンがOctcatになっていないかgitクライアントに設定したemailアドレスがGitHubのユーザーのメールアドレスと違う場合にこうなる。他のチームメンバーからすると「謎のアイコンの人がコミットしてる!」という見た目になる。これをやると他のメンバーに「ああ、普段コード書いてない(GitHubを使ってない)人なんだな・・・」という生暖かい視線を浴びる羽目になる。無意味なファイルがないかgeneratorが作成した無意味なファイルは削除しよう。実装のないmoduleとか、中身のないtest、fixturesとか。「これはgeneratorが勝手に作成したんで」というと先輩にすごく怒られる。一つ一つどんな意味を持っているのか調べよう。gemのgroupが適切かtestでしか使わないgemがgroup無しで全groupで読み込まれている。必要なところだけにしよう。不要なrespond_toがないかjsonでアクセスする必要が無いのにscaffoldのコードをそのままで残っている。htmlだけが必要ならrespond_toやformatは削除しよう。削除するときにrespond_toとformatが何をやっているのか調べた上で消すのも忘れずに。何でもリファクタリングと言ってないかリファクタリングはプログラムの振る舞いを変えずに内部構造を変えることなので、ちょっとした修正という意味で使っていると先輩に怒られるというあるある。秘密の情報がコミットされていないかoauthのsecretとか。コード中では環境変数にしておこう。これをやると、gitで過去を修正したとしてもGitHubのキャッシュに残ってしまい、完全に消すにはGitHubのサポートに連絡するとか面倒なことになる。チームメンバーが「あ〜あ」という顔になる。.gitignoreは適切か.DS_Storeはmacだけのファイル。.ideaはJetBrainsのエディター独自のファイル。いった特定の環境の人向けのファイルは.gitignoreに含めるべきじゃない。プロジェクト毎の設定じゃなくて自分のマシン固有の設定に書くべき。大量の依存gemがコミットされていないかgemのインストール場所をvendro/bundleとかにしてあって、その中にある大量のgemのファイルがコミットされてしまっていないか確認すること。ネイティブバイナリが含まれたgemもあるので環境によって違うので各自がインストールするものです。マジックナンバーが無いかこれ。Metzルールというものがあります。そこまで徹底しなくて良いですが、何十行もあると「見づらいな〜、なんとかならない?」ってなります。+0000ActionMailer::PreviewでActiveRecord::FixturesSetが読み込まれなくなった5.2系では読み込まれてたんだけど、6.0.1にしたらデフォルトでは読み込まれなくなってるみたい。zeitwerkになったからかしら。手動でrequireすればOK。「開発環境のユーザーのパスワードって何?」みたいな情報の共有って面倒ですよね。any_login入れちゃうのがいいかも。any_loginを入れると画面の左下にアイコンが出てきて、そこをクリックするとユーザーが一覧できるプルダウンメニューが出てきます。それを選択するだけでそのユーザーでログインできるというもの。似た仕組みを用意してる人が多いとは思いますが、無いなら導入おすすめです。Sorceryなど色々対応してます。フィヨルドブートキャンプのアプリに入れてみました。養成読本をいただきましたー。rails6になって新しく押さえておかなきゃいけないところをチェックしたかった自分にはちょうど良い本でした。これらはRailsGuideでもまだWIP状態なので本にまとまってるのはわかりやすかった。DatabaseさらにWebpacker、StimulusについてはREADME・公式サイト以外の情報はあまりないので少しでも記述されている本は集めたい気がします。testunit(minitest)信者として一番良かったのは、rspecじゃなくてminitestでのテストを一通り説明してあるところ。これの本は人によって自分が詳しく知ってるところ、弱いところが違うのでありがたい箇所も人それぞれだと思います。Hints知らなかったので助かった)ちょっとだけRailsから離れてて復帰した人、Rails6の新機能を押さえたい人にとっては最適な本だと思います。test:systemも実行するあえて分けられているのでその認識の上でやるならば、Rakefileに下記を追加する。+0000RubyとRailsの学習ガイド事前にレビューさせていただいた、技術書典6で配布されたRubyとRailsの学習ガイドを@igaiga555さんからいただきました。みせこれからrubyの勉強を始める人に最適のガイド。傍らに置いておけば、わからない用語が出てきたときには「これに載ってたやつだ」となるかもしれない。見て思ったのはむしろRuby・Railsをキーワードに勉強始めてる人の方が役に立つかもしれないということ。「これからどの方向に深めていけばいいのか」がわかりやすいので。これとRuby超入門を読めばかなりスムーズなスタートがきれるんじゃないでしょうか。フィヨルドブートキャンプでは新しく来る人に配ろうと思っております。さんがエントリーを書かれていました。Qiitaこちらに対する僕の考えも書いておこうと思います。(こういうのってブログっぽいですね!)created_atでソートするときはcreated_atにインデックスを貼る。意図が無い場合はソート自体しない。created_atでソートしない場合は貼らなくて良い。元エントリーもそれ前提で書いてました。2は「idでソートしたい」という意図がない場合「とりあえず何らかのソートをしなくちゃ」と思ってる場合はソート自体しなくて良い。ランダムなuuidでソートするのとソートしないのと変わらんと思う。ソーシャルゲームとかその他の超膨大なデータを処理する時にパフォーマンスの問題でこの前提をあえて崩すのは良いと思う。非正規化と似たようなもん。基本はidでソートしない方が良いということ。+0000idの順番に依存しないコードを書こう最近レビューでよく書くのでまとめておきます。指摘idでソートするとか、idがインクリメンタルな数字ということを前提とするコードは避けよう。古い順に並べたいんだったらcreated_atとかが作成日なんだから「古い順」ということをより表現していることになる。理由idをuuidとかに変えた場合バグになる。古いものを取ろうとしてidでソートしてfirstとかやっちゃいかん。管理画面のユーザー一覧をid降順でソートしてて、最近追加されたユーザーは一番最初にきてたのuuidにしたら並びが変わった・困るとお客さんに言われることになる。komagataのブログMicrosoft系のライブラリやフレームワークもuuidがidのこと多い。railsもfixturesではidはランダムに入るのでidがインクリメンタルな数字という前提のテストはコケる。Post.find(params[:id])むしろidはidentifierなんだから本来の使い方。気をつけるのはソート。HerokuブートキャンプのアプリをDEPRECATEDなpaperclipからactive_storageに移行した。keyがそのまま入ってて改行のせいでうまく行かなかったりとかいつもハマる。エラーメッセージの内容も原因解明にあまり役に立たなくて結局ガッツリデバッグすることになって時間がかかる。Herokuでの自分的ポイントはGCSからダウンロードできるJSONをそのまま環境変数に入れること。storage.ymlはこんな風にするのがよい。"bootcamp-fjord-jp"こういう感じで入れておく。/path/to/bootcamp.json)"実際にちゃんとconfigの各値が読めてるかどうかはActiveStorage::Service#configあたりをデバッグすればよい。+0000草が生える機能を追加フィヨルドブートキャンプでも草が生えるようにしました。「Githubと同じ色だと紛らわしいな」とか「Gtihubと違って一年も勉強してたらやばいから3ヶ月表示ぐらいがいいな」などあり、もうちょっと変更していきたいと思います。