レス数が1スレッドの最大レス数(1000件)を超えています。残念ながら投稿することができません。
アニメ一話見終わるまでに4回食事出来る男
-
ｋｍ
-
126のレスがぐっときた
-
覚えて使って身につけるってループを1時間に何回転できるかやと思うわ
-
factory :user のブロックの中に owner 定義するのかも
-
ボクならbinding.pryして値を見てみますね
-
おはよう、何につまってるの？
-
Can't you read English!? Hahaha
英語だけだとダメってpeerstplayerに怒られたorz
-
FactoryGirl関係ないかもしれん
change{ introduction.user.reload.re_introductions_count } ってしてみて
-
多分順番として
1.Userを作る(キャッシュされる)
2.Introductionを作る
3. 1と2が関連付けられる
ここで introduction.user とすると 1 の状態が帰ってきちゃう
-
ActiveRecordの挙動がよく分かってないから難しいな
どの操作で副作用や永続化が行われてるんだ
-
カウンターキャッシュは3の時に走るから1の状態だと0のまま
-
それは 2 と 3 を一緒にやってる
1. user = User.create
2. introduction = Introduction.create
3. introduction.users << user
-
それはDBに取りに行ってるから新しいインスタンス生成して増えてるだけじゃないの？
1回目の取得時に変数に取得したユーザをバインドしとけば変わってないんじゃ無い？
-
user = Usre.first
Introduction.create
user.count
で見ると増えてないんじゃないのかって意味
-
こうなるはず
user = User.create
introduction = Introduction.create
user.count_cache #=> 0
introduction.users << user
user.counter_cache #=> 0
user.reload
user.count_cache #=> 1
-
30行目で変数にreloadの結果を代入してないから上手くいってないんじゃないの？
reloadって副作用があるメソッドじゃないよね？
-
Introductionの生成がユーザテーブルにデータを永続化してると思うから
永続化された後に再度DBからデータを取得しないと期待した値が取れないんだよね？
-
データベースに問い合わせないでメモリにあるやつを返してるんだと思う
-
永続化はとりあえず保存って意味で読んでくれていいや
-
テスト中に止めてtestDB見たら値が入ってるんじゃないかなぁ
おそらくIntroductionの生成時にUserテーブルに対して値を足してるから
その更新された値が必要であればDBからデータを取得しないといけないんだと思う
実行中のプログラム全てに対してチェックして変数の更新は行ってないんじゃない
-
さみゅい
-
Railsを深く触ったことはないけど他のMVCフレームワークだと妥当な挙動だしそうだと思う
DBについて完全にブラックボックス化されてないって言われてるのがこの辺じゃないかな
-
で、reloadっていうのは同じIDのオブジェクトに対して
再度DBから値を取得するメソッドだから上手くいったんだよね？
-
カウンターキャッシュのカラムは普通の方法じゃ更新できひん
-
え、reloadって副作用があるメソッドなのか
それはreload!あたりで実装したらよさそうな気がするけど
-
update は引数ハッシュやろ update(name: "新しい名前")
-
user = introduction.user.reload
でuserが新しいのが取得出来るのなら分かる
introduction.user自体を更新するのはそこ以外のコードの挙動を変える可能性があるから
introduction.user.reload!の方がいいと思うけどな
-
あ、いやActiveRecordの挙動について愚痴ってるだけだよ
破壊的なメソッドには!を付ける文化があるんだしそうしとけよって思った
-
そんな文化ないで
ruby標準のString#deleteも破壊的やし
-
あれ、deleteは破壊できじゃなかった
でもなんかあったで!ないのに破壊するやつ
-
>def xxx!
>「!」はメソッド名の一部です。慣用的に、 同名の(! の無い)メソッドに比べてより破壊的な作用をもつメソッド(例: tr と tr!)で使われます。
一貫してないのは知ってるし、一貫できてないのはクソだと思ってるけど
公式にドキュメントにこう書いてるよ
-
まぁArray#shiftやArray#popが破壊的だししょうがないと言えばそうなんだけど
自分がコーディングするならreload!って書きたいなぁって感じ
-
確かに統一された方が分かりやすいかもしれんな
Array#delete とか壊して欲しくないときある
でも慣れちゃう
-
PHP触ってるとその辺の挙動が全く一貫してなくて本当にクソだし
それに比べたら大分マシなんだけど
ちゃんと統一されてるとドキュメント調べたりpry使って挙動調べる機会が減るし嬉しい
-
なんでreload!じゃないかは多分 reload!.user とか
メソッドチェーンが気持ち悪くなるからだな
-
destroyの返り値ってなんなの？
-
destroyの後もキャッシュ読んでるんじゃね
-
あぁ、reload書いてない場合は0から0への変化に見えて落ちて
reloadした場合は1から1への変更に見えて落ちてるんじゃないのこれ
-
user = introduction.user
ってして user を検査したらどうなるの
-
28行目のreloadを書くか書かないかで失敗する理由が変化してると思う
-
1. re_introductions_count を調べる (1)
2. destroy する
3. re_introductions_count を調べる (キャッシュを読んで1)
introduction.user が 1と同じ状態やから変化してないように見えてる
-
rspecの挙動よく知らないけどこの文法を見るに
expectに渡したブロックが実行される前にchangeブロックが実行されて
expectブロック実行後にchangeブロックが再実行
changeブロックの実行結果の差がbyの引数と一致するか見てるのであってるのかな
-
167で合ってる
destroy しても introduction.user は更新されないから変化なしになってる
-
面倒くさいしexpectの外で
user_id = introduction.user.id
expectの中で
User.find(user_id).re_introductions_count
って書けばいいんじゃない？
別にそんなに分かりにくいわけじゃないし
-
明示的にUserテーブルの値を再確認しにいってるコードになるから
そういう意図のテストだって言うのはまぁ分かりやすくなってると思う
-
あれ、changeの中で毎回reload呼ぶコードにしたら上手く動くよね？
無理？
-
まぁActiveRecordの挙動に振り回されないって意味では分かりやすいよね
いいと思う
-
お出かけ？
-
カウンターキャッシュに変更があったらキャッシュも更新して欲しいぜ
コスト高いんかな
-
どんな服買うの
-
Modelのオブジェクトの変更をトリガーにして
メモリに乗ってる変数を毎回全て走査するのはコスト高すぎると思う
無理じゃないだろうけどある程度以上のアプリケーションになると現実に則してないはず
-
最近流行ってきてるFunctional Reactive Programmingでまたそういうのが話題になってるけど
あれも全変数を走査するんじゃなくてバインディングしておく変数を指定しておく感じだからな
そういうのが取り入れられるのはありえそうだけど
-
あとでテスト書くのが大変ならテストファーストで実装するのも試してみたらいいと思うよ
先にテストを書いておいてそれが動くように実装していくやつ
TDDとかでぐぐれば色々出てくる
-
テストが終わったらデータベース消すやつして
-
仕様を決める＞実装するじゃなくて
仕様を決める＞テストを書く＞テストが動くコードを実装する
ってやり方
-
テストが書きやすいコードを最初からかけるってのがメリットなのはあるね
テストを考えずにコードを書くとテストが書き辛くてコードを書き直す事って結構あるし
-
自分が今の思いつきで適当に書き殴るより
一昨日ドリコムの中の人がテストファースト勉強会ってので使ったプレゼンが上がってたから置いとく
http://www.slideshare.net/sue445/ss-43546341
-
ソシャゲ作ってたりする会社
割と有名だと思う
-
ボクはエラー通知を入れてユーザーにテストさせてます
もしかしたらエラーをはかずに誤動作してるかもしれません
-
そう、メールが送られてくる
-
頭の中で思いついた挙動をドキュメント書く代わりに仕様として定義しておけるのはいいかなー
全部テストファーストで実装するのはやってみると分かるけどかなり辛い
-
テストの書き方1つ取っても境界値のテストをちゃんと書くとか
やり方が色々あるし難しい
大きめのリファクタするときは個人でもテストは役に立つよ
-
rails updateするたびに全部手動で確認はダルいで
-
30点以下の人を赤点と判断するプログラムがあったとして
29点の時の挙動と30点の時の挙動が正しく動いてるか確認するとかそういうの
railsはすぐにサポート終わって仕様が変わるから追従していかないと
脆弱性放置されて公開不可になるとかありそう
-
きっちりしたものを作りたくなったときに
いきなりちゃんとしたテストが網羅的に書けるのかって問題はありそう
-
最悪モデルだけ書いときゃええ
あとはユーザーにテストさせましょう
-
あ、僕も基本的にテストはModelだけでいいと思ってます
ControllerとViewのテストは仕様変更に対するコストが高すぎる
-
モックとスタブはテスト書くときはどの言語でもかなり使うから・・・
-
カメラ屋君と楽しんできて
-
服かったらファッションショーたのまいｗ
-
配信してお願い
-
蛇にならないでお願い
-
今のにわとりって配信者に似てた
-
最近性欲の調子どう？
-
ありがとうございますを付け足して欲しかった
-
自分で自分のサイトをスクレイプ的な
-
どうも、こんばんわ
部屋壁のリノベーションはうまくいきましたか？
-
真っ白やｗ
-
マイクで宇多田の音拾ってますの？
-
その適当なブログをだな
-
ハートル先生とかqiitaあたりからひろった方が
-
宇多田ひかるって、みのりんに似てね？
-
勇次郎さんの作ったオムライスがたべたいのぉ
-
何用？
-
カメラ越しだからメッシュに見えて
スポーツ系かと思ったわ
-
でもお高いんでしょう？
-
裾上げタダ？
-
きこりになろう
-
高いけど超頑丈だわなぁ
-
靴値切るとか初めて聞いたがｗｗ
-
find("#ID") じゃ駄目なんか
-
click_link "#ID" は？
-
HTMLぶっ壊れてないよね？
ぶっ壊れてると動かないことあるらしいけど
-
#付けないでみるとか
click_link "ID"
-
こんばんわやま
今日朝まである？ｗ
-
終わらないでお願い
-
ドットインストールのHTML終わったよ
今からCSSだよ
-
ピーヒョロからのツクツクツンツン
-
この曲１番好き
-
なんなぁきとるやん?( ‘ω’ )?
-
github有料いきますか
|
|
掲示板管理者へ連絡
無料レンタル掲示板
