select文でASキーワードを利用すると列名に別の名前をつけることができる
三文小説というサービスを運用しているので、それを例にする。DBは postgresql。
作品テーブルがあって、id, user_id, titleをselectしてくるクエリと、その結果は次のようになる。
select id, user_id, title from works; id | user_id | title ----+---------+---------------------------------- 14 | 1 | テスト・テスト 3 | 1 | 残念なカバjjj 4 | 3 | わっしょい野田 5 | 4 | おれは芥川 6 | 5 | まっかか
ASキーワードを利用すると、結果として表示される列名に別名を用いることができる。user_idを tysya（著者）, title をdaimei（題名）に変更する。
select id, user_id as tyosya, title as daimei from works; id | tyosya | daimei ----+--------+---------------------------------- 14 | 1 | テスト・テスト 3 | 1 | 残念なカバjjj 4 | 3 | わっしょい野田 5 | 4 | おれは芥川 6 | 5 | まっかか
自然言語に近づけたり、長いカラム名を短く表現するときなんかに便利そう。
参考
（了）
【小ネタ】SQLクエリを発行した後の結果がターミナルに表示されるが煩わしいときに使える？
先輩に教えてもらった小技だ。rails cで変数を格納したいだけのときに、わざわざターミナルにずらっと結果を出力して欲しくないときに使える。変数に格納する回数が多いときに使えるかも。。。
一般的な書き方だと下記のようになる。オブジェクトの詳細が出力される。
irb(main):030:0> w = Word.last Word Load (5.6ms) SELECT "words".* FROM "words" ORDER BY "words"."id" DESC LIMIT $1 [["LIMIT", 1]] => #<Word:0x00007fba14c9a4c0 id: 163, name: "テキトー", start_at: nil, end_at: nil, created_at: Mon, 18 Jul 2022 16:55:28.281496000 JST +09:00, updated_at: Mon, 18 Jul 2022 16:55:34.531823000 JST +09:00, act...
毎度上記のようにオブジェクトの詳細は見たくない！というときに、下記のように末尾に;nilを加える。
irb(main):031:0> w = Word.last;nil Word Load (0.4ms) SELECT "words".* FROM "words" ORDER BY "words"."id" DESC LIMIT $1 [["LIMIT", 1]] => nil
こうすると、nilを最後に評価してくれるので余計な？出力がされない。便利？
(了)
GithubのPRからpatchファイルに必要な差分を作る方法
ときにパッチファイルが必要になることがある。git diff コマンドで作成することはできるが、今回はGithubのPRから作成する方法を教えてもらったのでメモ。とはいえ簡単で、PRのURLの末尾に.diffを加えるだけだ。
あとはこちらを、hoge.patchなどのファイルにコピーしてあげればよい。便利。
[Git] 一時的なコードの変更をパッチファイルに出力してチームメンバーに共有する | DevelopersIO
（了）
同じ技術書（チェリー本）の２周目を終えて
Railsエンジニアとして転職するにあたって勉強をはじめて半年くらい経ってからはじめて読んだように思う。そのときはエンジニアとしての知識が不足していたので、文章の意味が良くわからなかったし、わからないから手を動かさずに何となく読んだ。procとyeildって意味わからんという気持ちを抱いたことが懐かしい。エンジニアに転職してもうすぐ２年になる。まだわからないことだらけだ。なので基礎に立ち戻ることにした。ということで、第２版が発売されたということで物理本を買って読んだ。そして読み終えた。
わかることが増えてる！というのが単純かつ率直な意見だ。とてもうれしい。なんだかんだと成長しているのではなかろうか。eachやmapなどにあたふたしていた頃が懐かしい。やはり実務でコードを読む・書く経験が効いている。ああ、読んだし書いたな、と何度も読書中に思った。また、きちんと手を動かしながら読書をした。TDDの開発の基本的なフローを体験できたのでよかった。厳密なTDDでなくてもいいから開発スタイルに組み込みたいと思っていたから。
実務経験を経て、自分の課題をひしひしと抱えている状態で本にあたると、やはり知識の染み込み方が違うように思える。またしばらく働いて、課題を抱えて本書に戻ってきたい。
（了）
的確な情報把握能力と胆力の向上が必要
だととても思うことがあった。
開発した機能がリリース直前に動かない、という報告があった。どうやら別チームがコードをリファクタリングした際に誤っていたようだった。そこで、簡単な修正を依頼した。それで事は済むはずだった。しかし、修正をした開発者のローカル環境で修正したはずの機能がバグっていると報告があった。話を聞いてみると確かにバグっていた。この瞬間に気が動転した。
ヤバい！バグだ！リリース近くて修正する時間がない！どうしよう！そこの機能を塞ぐべきか！どうやって！？QAテストはパスしたはずなのになぜ！？顧客に迷惑がかかる！当社のブランドに傷がつく！
というような思考がぐるぐると頭のなかを跳ね回り心拍数はどんどん上がった。冷静さを失っていた。こんな開発者じゃだめだ、と思考は転じていく。かろうじて、まずは自分のローカルでバグが再現するかテストしようと思いつく。ここでローカル環境がぶっ壊れてストレスかさらに高まる。実際やってるとバグは再現はしなかった。さらに混乱。冷静に考えてみて、最新のリリース用ブランチをステージング環境でテストしてみたところ、動作に問題ないようだった。つまり、あるローカル環境でのみ起きる再現性のないバグだったようだ。ひと段落。
これにメンタルポイントと時間をとられた。抱えていた喫緊の別のタスクは上長に引き取ってもらった。
見ての通り、右往左往するのが早い。自分のローカルでテストする、ステージングでテストする、という確認をせずにバグだとから騒ぎしている。この失敗からわかることは、まずは状況把握能力が足りていないことだ。いま状況はどうなっているのか？それを把握するには具体的にどうすればいいのか？何から手をつけると問題の切り分けが素早くできるのか？という一連の問いへの回答を集めるべきだった。そのプロセスをぶっとばしてコードにバグがあると信じてコードを、眺め始めてしまった。
すぐに手をつけることが最も早く事態を収拾できるも思い込んでいる節がある。これは自分の欠点だと気づくことは何度かあった。その欠点が浮き彫りになったのだ。この対処法は何なのか。必要な情報を見極める能力なのかな。経験、だとすれば今回のことを糧にするしかない。
あとは単純に胆力が必要に思う。動じないというか、不確定の情報に振り回されない力というか。場数なのかなー。
的確な情報把握力を鍛える。
（了）
安易にresucueを使わない
チェリー本の９章「例外処理を理解する」を読んだ。初学者の頃に読んで、なんとなく頭の片隅にあったことが少し整理できた。安易にresucueを使ってはいけいない、が印象的だった。
resucueを利用すると例外を補足できる。なんか問題が起こったときのために resuce しとけばいいのでは、と思っていた。しかし致命的なデメリットがある。 しかし安易にresuceuを利用し、その後続の処理に考慮不足があれば、例えば、データの構造がおかしくなってしまう場合がある。それ自体に修正のコストがかかる。もし決済のデータであれば、修正にはとても神経を使うことになる。しかも本番データ！ 考えただけで冷や汗が出る。他にも例えば、歪なデータそれ自体はクリティカルではないが、そのまま後続の処理のなかで、バグを起こすかもしれない。その場合、なかなかバグの原因を突き止めることができないかもしれない。考えるといろいろあるな、、、。なので、安易なresucue はしないほうがよい、ということだ。もちろん適切に利用すれば、大変便利。
最近、チケットでバグ修正のものが多かったせいか、バグや例外に対する感度が上がっている。もっといいコードが書きたい、事業の生産性を高めたい、という気持ちが、自分で把握する以上に大きいことに気づいたのもよかった。仕事っていいですね。
（了）
ある日時未満、という条件でwhere文を作成する方法
例えば、先月の月初未満に作成されたUserのレコードを抽出する方法はこんなふうに書く。
User.where('created_at < ? ', Time.current.prev_month.beginning_of_month)
参考
（了）
