# カレントユーザに所属する最新のコンテンツについて、 # 公開済みならそのタイトルを、未公開なら「（下書き）」を返す latest_title = current_user.contents.last.then { |content| content.published? ? c.title : '（下書き）' }
Object#yield_self と Object#then は、ブロックの中身を評価した結果を返す。主にメソッドチェインしてちょっとした処理をすることで役にたつ。
Ruby 2.5から Object#yield_self が導入され、Ruby2.6からそのエイリアスとして Object#then が導入された。
import pandas as pd df = pd.DataFrame(some_list).astype(int)
DataFrame.astype(type) で、好みの型に変換できる。
ただし、 timezone-naive な型（タイムゾーンが付加されていない）を timezone-aware な型（タイムゾーンが付加されている）へ変換するのは非推奨になっており、未来のバージョンではエラーが raise される予定になっている。その場合は Series.dt.tz_localize() を使用することが必要。
find_each を使おう。 batch_size を指定すれば、一度に取得するレコード数を制限できる。
Model.find_each(batch_size: 100) do |model| ~~~ end
#all は、一度に全てのレコードを取得するので、まずデータベースに負荷がかかってしまう。さらにその結果を全てメモリ上に展開するので、Railsにも負荷がかかってしまう。
find_each を使えば、一度に取得してくるバッチサイズを指定することで、大量のレコードを取得してしまうことを防げる。
# Python variable = 'Trueの時の値' if condition else 'Falseの時の値'
RubyやJavaScriptだとこんな感じ。
# Ruby or JavaScript variable = condition ? 'Trueの時の値' : 'Falseの時の値'
ちなみに、三項演算子は英語で Ternary operator という。
asyncDataもfetchも、どちらも非同期にデータを外部サーバへ取りに行く処理を定義するための関数である。どちらも似たような処理ができるものの、2つ用意されているという事はそれぞれに異なる用途がある事を示す。
ここではCSR (Client-Side Rendering) の場合を考えるものとする。
asyncData と fetch の違いasyncData は fetch より先に呼ばれるasyncData は beforeCreate フックの手前で呼ばれる。一方で、 fetch は created の後で呼ばれる。したがって、 asyncData の中で return した値は fetch の中で利用可能だが、その逆はできないということになる。
よりわかりやすいライフサイクルの説明が公式から提供されているので、参考にされたい：
この図は クリエイティブ・コモンズ 表示 - 改変禁止 4.0 国際 ライセンスの下に提供されています。
(c) NuxtJS
fetch は this にアクセスできるが、 asyncData はできないasyncData では this が提供されない。その代わりに、 context にアクセス可能である。だいたいのことは context で提供されるいずれかの引数でできると思われる。
asyncData は return することで、 this に値を定義することができる。一方、 fetch は data で定義した値を変更することまでしかできず、新規に定義するところまではできない。
こう見ると asyncData を使っておけば良さそうに見えるが、 Component の中では asyncData を使用できない制限があるので、その場合は fetch を使う必要がある。
$ export SOOME_VALUE=abcde $ echo ${SOME_VALUE?} sh: SOME_VALUE: parameter null or not set
SOME_VALUE を定義したつもりで、できていないときに気付くことができる。
変数名の後ろに ? を付けると、その変数が定義されていないときにエラーを出して止まってくれる。
値が入っていないといけないような変数であれば、 ? を付けておけば呼び出された場合に値が入っている事を保証できる。
{} === {} // => false
JavaScriptでの比較は、落とし穴が多い。詳しくは参考に挙げたページを見てもらえるとわかるが、 +0 === -0 が false になったりと良く知っていないとハマりがちである。
ではどうやって object 同士を比較すれば良いか、というのが気になるが、一番確実なのは object のうち、どれを比較すれば良いかを自分で管理して、それを比較するのが良いのではないだろうか。例えば、Userを表す object を比較する際は、 user.id 同士を比較するといった具合である。
なお、Rubyであれば Object#==? のオーバライド、Pythonであれば __eq__ のオーバライドすることで、オブジェクト同士が比較された際の挙動を変えられる。
