idの順番に依存しないコードを書こう - komagataのブログ

このエントリーに @jnchito さんがエントリーを書かれていました。

【Rails】idでソートするか?created_atでソートするか? 〜 Re: idの順番に依存しないコードを書こう - Qiita

こちらに対する僕の考えも書いておこうと思います。(こういうのってブログっぽいですね!)

  1. created_atでソートするときはcreated_atにインデックスを貼る。
  2. 意図が無い場合はソート自体しない。

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なんだから本来の使い方。気をつけるのはソート。

つづき

created_atでソートする場合はインデックスを貼る - komagataのブログ

ブートキャンプのアプリを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あたりをデバッグすればよい。

フィヨルドブートキャンプでも草が生えるようにしました。

Image from Gyazo

最初は色も全く同じだったんですが、実装したことに満足して冷静になってみると、

「Githubと同じ色だと紛らわしいな」

とか

「Gtihubと違って一年も勉強してたらやばいから3ヶ月表示ぐらいがいいな」

などあり、もうちょっと変更していきたいと思います。

超実践的プログラミングスクール フィヨルドブートキャンプ

僕のイメージ(というか願望)としてはUIでComponentというからには下記ができて複数プロジェクトで使い回せてほしい。

  • コメント投稿
  • コメント編集
  • コメント削除

Image from Gyazo

昨今のWebアプリのUIに対しての要求は上がっているので

「今どきページ遷移しないで投稿・編集・削除したい」

という意見は最もだと思う。

vue.jsでいつも作ってるけど、いつもは以前のプロジェクトからcomments.vueなどのファイル一式(下記のようなやつ)をコピーしてきて編集する。

comments component

そこそこ工数かかる。こんなに編集とテストが必要では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サービスの開発に入っていただける方募集しております。

最近リリースした3ヶ月ぐらいのプロジェクトでRailsのバージョンも最新なのでまだそんなにごちゃごちゃしておりません。

現状エンジニアさんがなかなか見つからず、僕含めて知り合いの工数をかき集めてやっている状態です。

  • 僕:1日/週
  • Tさん:2日/週
  • Oさん:2日/週

3人分集めてやっと一人分といった形なので、週5日できる人がいるといいなーとお客さんから言われております。(現状だと連絡があっても常に受けられる状態とは限らないので)

使っているいる技術

  • Rails
  • Heroku(Review App)
  • CiercleCI

プロジェクトの進め方

1スプリント一週間で、毎週火曜日に振り返り・計画ミーティングをリモート(appear.in)でやっています。Issueの管理はGithub Projectでやっています。

募集要件

  • できれば週5日できる方(場合によって3日以上でも大丈夫です)
  • リモート化(常駐も可能です)
  • Railsでの開発経験がある方。

ぶっちゃけどうなの?という話には直接お答えしますので、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エンジニアになるためのスクールをやっています。

FJORD BOOT CAMP(フィヨルドブートキャンプ)

「どのレベルになったら就職できるの?」

という点がイメージできないと、就職したい人にとってわかりづらいなと思ったので明確にしておきたい。

戦力として計算できるRailsエンジニアとは

僕の考える、Railsエンジニアとして就職できる最低レベルは、

「少しでもプラスの戦力として計算できる」

というものです。

「Issueを一人でこなせる」

といっても良いかもしれません。

「は?みんな10の戦力持ってるところに1とかじゃ困るんだけど?」

と思うかもしれませんが、Railsプロジェクトにとってほとんどの人類は1の戦力も無くて、マイナスです。

Railsチュートリアルを終わったばっかりで実務レベルの開発したことないぐらいの人もマイナス戦力です。

「教えるのに大量のパワーが割かれて、居ない方がプロジェクトが進む」

という状態がマイナス戦力です。

Railsプロジェクトのリーダー的な役割をした人なら感覚的にわかると思います。

「Rails経験無くてJava経験だけの人が2人送られてきても困るなぁ・・・」

これがマイナス戦力です。

「多少の教育コストはかかるけど、レビューをしっかりやればトータルで見れば助かる」

このレベルがプラス戦力です。

「Railsのコードは書かせられないけどテスト仕様書を書いててもらおう」

こんな工夫が必要な場合、マイナス戦力です 😅

プラス戦力になるための工夫

このイメージが固まってからカリキュラム終盤の内容も変わりました。

  • 弊社プロダクト(怖話など)へPRを送って5回採用される。
  • Railsプログラムのアルバイトの斡旋
  • DB設計のカリキュラム追加
  • RESTful Webアプリ設計のカリキュラム追加
  • メンターとペアプロするカリキュラム追加。

Railsの機能を一通り覚えただけじゃ駄目で、実際のプロジェクトに入るには必須の知識がかなりあります。

弊社としては一般的なプログラマー新人研修もやっているのでその中でこの辺ももっと固めていきたい所存です。

  • 早さ
  • 機能
  • 安定性(バグの少なさ)

これらはトレードオフ。そして、

実装力 = 早さ x 機能 x 安定性

https://gyazo.com/e85c2b4af83c473d5cad53c2b3e90dbc

しかし、レベルアップすることで、早さそのままで多くの機能を実装できたり、早さそのままでバグが少なく作れるようになったりするんだよね。

割り振れるスキルポイントが増えるみたいな感じで。

Railsのおかげでちょっと早く作れるようになったからっつって、

「俺、作り込むよりプロトタイプ作るのが得意なんだよね。早さと完成度ってトレードオフじゃないですかぁ?」

とか言ってないで、同じ早さのままもっと作り込んだもの作れるようになれ!バグ減らせ! > 俺

https://gyazo.com/d6bd00fa98c7ad07d29bf5aec84c4924