idの順番に依存しないコードを書こう - komagataのブログ
このエントリーに @jnchito さんがエントリーを書かれていました。
【Rails】idでソートするか？created_atでソートするか？ 〜 Re: idの順番に依存しないコードを書こう - Qiita
こちらに対する僕の考えも書いておこうと思います。（こういうのってブログっぽいですね！）
1はそのままですね。created_atでソートしない場合は貼らなくて良い。元エントリーもそれ前提で書いてました。
2は「idでソートしたい」という意図がない場合「とりあえず何らかのソートをしなくちゃ」と思ってる場合はソート自体しなくて良い。ランダムなuuidでソートするのとソートしないのと変わらんと思う。
ただ、ソーシャルゲームとかその他の超膨大なデータを処理する時にパフォーマンスの問題でこの前提をあえて崩すのは良いと思う。非正規化と似たようなもん。ただあくまで基本はidでソートしない方が良いということ。
最近レビューでよく書くのでまとめておきます。
idでソートするとか、idがインクリメンタルな数字ということを前提とするコードは避けよう。古い順に並べたいんだったらcreated_atとかが作成日なんだから「古い順」ということをより表現していることになる。
idをuuidとかに変えた場合バグになる。
古いものを取ろうとしてidでソートしてfirstとかやっちゃいかん。
管理画面のユーザー一覧をid降順でソートしてて、最近追加されたユーザーは一番最初にきてたのuuidにしたら並びが変わった・困るとお客さんに言われることになる。
rails+postgresでidにuuidを使う - komagataのブログ
Microsoft系のライブラリやフレームワークもuuidがidのこと多い。
railsもfixturesではidはランダムに入るのでidがインクリメンタルな数字という前提のテストはコケる。（偶然動いたりするがそのうちコケる）
もちろんだけど、こういうコードは全く問題ないヨ！
@post = Post.find(params[:id])
むしろidはidentifierなんだから本来の使い方。気をつけるのはソート。
ブートキャンプのアプリをDEPRECATEDなpaperclipからactive_storageに移行した。
GCSのcredential関係ってPrivate keyがそのまま入ってて改行のせいでうまく行かなかったりとかいつもハマる。エラーメッセージの内容も原因解明にあまり役に立たなくて結局ガッツリデバッグすることになって時間がかかる。
ActiveStorage + GCS + Herokuでの自分的ポイントはGCSからダウンロードできるJSONをそのまま環境変数に入れること。
storage.ymlはこんな風にするのがよい。
config/storage.yml:
google:
service: GCS
project: "bootcamp-224405"
credentials: <%= ENV["GOOGLE_CREDENTIALS"] %>
bucket: "bootcamp-fjord-jp"
こういう感じで入れておく。
$ heroku config:set GOOGLE_CREDENTIALS="$(< /path/to/bootcamp.json)"
実際にちゃんとconfigの各値が読めてるかどうかはActiveStorage::Service#configあたりをデバッグすればよい。
フィヨルドブートキャンプでも草が生えるようにしました。
最初は色も全く同じだったんですが、実装したことに満足して冷静になってみると、
「Githubと同じ色だと紛らわしいな」
とか
「Gtihubと違って一年も勉強してたらやばいから3ヶ月表示ぐらいがいいな」
などあり、もうちょっと変更していきたいと思います。
僕のイメージ（というか願望）としてはUIでComponentというからには下記ができて複数プロジェクトで使い回せてほしい。
昨今のWebアプリのUIに対しての要求は上がっているので
「今どきページ遷移しないで投稿・編集・削除したい」
という意見は最もだと思う。
vue.jsでいつも作ってるけど、いつもは以前のプロジェクトからcomments.vueなどのファイル一式（下記のようなやつ）をコピーしてきて編集する。
そこそこ工数かかる。こんなに編集とテストが必要ではComponentとは言えない（ように思う）。
外部からAPIのURLを渡すぐらいで上記が全部できるようになりたい。comments componentに関してはnpmでインストールしたい。
今のやり方ではAPIが違うだけでかなり変更が入る。APIやcommentが付く対象（postとか）が変わることに対応しようとすると、comment取得やコメント更新のXHR処理自体を外から注入する必要が出てくる。使いまわしたいJSコードの大半がそこなので、それを毎回書いて外から注入しなきゃいけないのでは全然楽になってない。
「今どきテキストエリアはMarkdownで書きたい」
という要求に対しては下記のようにnpmにできたので気軽に
「いいっすよ」
と言えるようになった。
textareaを画像アップ可能なmarkdown editorにするnpmモジュール - komagataのブログ
しかしコメント機能に関しては、
「できますが・・・ちょっとだけかかるかも・・・しれませんねぇ・・・」
という状態。vueだろうがreactだろうが同じだと思う。
何かいい方法は無いものかなぁ。
validates :email, format: { with: URI::MailTo::EMAIL_REGEXP, message: "Emailに使える文字のみ入力してください" }
Railsでやっている不動産系のWebサービスの開発に入っていただける方募集しております。
最近リリースした３ヶ月ぐらいのプロジェクトでRailsのバージョンも最新なのでまだそんなにごちゃごちゃしておりません。
現状エンジニアさんがなかなか見つからず、僕含めて知り合いの工数をかき集めてやっている状態です。
３人分集めてやっと一人分といった形なので、週５日できる人がいるといいなーとお客さんから言われております。（現状だと連絡があっても常に受けられる状態とは限らないので）
１スプリント一週間で、毎週火曜日に振り返り・計画ミーティングをリモート（appear.in）でやっています。Issueの管理はGithub Projectでやっています。
ぶっちゃけどうなの？という話には直接お答えしますので、Twitterの@komagataやFacebookでお気軽に連絡いただければ〜
これが拾えないのってみんなどうしてるんだろう？
class PostsTest < ApplicationSystemTestCase
test "GET /posts/xxxx" do
assert_raises(ActiveRecord::RecordNotFound) do
visit "/posts/xxxx"
end
end
end
例えば、「非公開のpostは見れないことをテストしたい」とかの時。begin...endでも拾えないようで困った。
仕事でフィヨルドブートキャンプというRailsエンジニアになるためのスクールをやっています。
「どのレベルになったら就職できるの？」
という点がイメージできないと、就職したい人にとってわかりづらいなと思ったので明確にしておきたい。
僕の考える、Railsエンジニアとして就職できる最低レベルは、
「少しでもプラスの戦力として計算できる」
というものです。
「Issueを一人でこなせる」
といっても良いかもしれません。
「は？みんな10の戦力持ってるところに1とかじゃ困るんだけど？」
と思うかもしれませんが、Railsプロジェクトにとってほとんどの人類は1の戦力も無くて、マイナスです。
Railsチュートリアルを終わったばっかりで実務レベルの開発したことないぐらいの人もマイナス戦力です。
「教えるのに大量のパワーが割かれて、居ない方がプロジェクトが進む」
という状態がマイナス戦力です。
Railsプロジェクトのリーダー的な役割をした人なら感覚的にわかると思います。
「Rails経験無くてJava経験だけの人が2人送られてきても困るなぁ・・・」
これがマイナス戦力です。
「多少の教育コストはかかるけど、レビューをしっかりやればトータルで見れば助かる」
このレベルがプラス戦力です。
「Railsのコードは書かせられないけどテスト仕様書を書いててもらおう」
こんな工夫が必要な場合、マイナス戦力です 😅
このイメージが固まってからカリキュラム終盤の内容も変わりました。
Railsの機能を一通り覚えただけじゃ駄目で、実際のプロジェクトに入るには必須の知識がかなりあります。
弊社としては一般的なプログラマー新人研修もやっているのでその中でこの辺ももっと固めていきたい所存です。
これらはトレードオフ。そして、
実装力 = 早さ x 機能 x 安定性
しかし、レベルアップすることで、早さそのままで多くの機能を実装できたり、早さそのままでバグが少なく作れるようになったりするんだよね。
割り振れるスキルポイントが増えるみたいな感じで。
Railsのおかげでちょっと早く作れるようになったからっつって、
「俺、作り込むよりプロトタイプ作るのが得意なんだよね。早さと完成度ってトレードオフじゃないですかぁ？」
とか言ってないで、同じ早さのままもっと作り込んだもの作れるようになれ！バグ減らせ！ ＞ 俺
