【RoR】Ruby on Rails Part20©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Railsはビュー周りがダメだな
なぜフォームヘルパーなどという腐ったものを作り出したのか?
普通にHTMLを書けばいいじゃないか そういう問題じゃないんだけどねw
よく知られた方法があるのだから
それを使いましょうと
フォームなんか
<form name="model[name]" 略
でいいじゃんかと
なんでそれをわざわざRubyのコードに置き換えるのかと 日本だと、10万円/1か月ぐらいのRoR案件もあんぞw あれって 中間が抜いてるせいなのかね? 元々が安いのかね? >>584
中間がガッツリ抜いて、第7, 8次とか第10次下請けとかまで降りてくるもんなー。 多重下請けで中間が抜き過ぎてるから下請けじゃない自社開発も給与が下がるマジック 1社、間に入ると、3割抜かれる
0.7 ずつ掛けていくと、
(顧客) 100 → 70 → 49 → 35 → 25 → 18
ハローワークでは、2次受けまでにするように言われる。
つまり、大手SIer の直受けまで。70 の所
それよりも下層の会社に、就職しないように言われる。
49 の所以下の会社 レイオフできるアメリカ
整理解雇の四要件で解雇しにくいので派遣をつかう日本 2次受けより下の仕事したこと無いけど会社とかどんな感じなの? 年金事件のは、別会社じゃなくて、単に同一会社の支店を、中国に作っただけ
国が異なるから、同一会社の支店を作れないから、別の会社を設立しただけ。
それが別の会社と、みなされただけ
外資系の会社の、日本法人と同じ。
便宜上、別の会社とみなされる 入力ミスって報道だけどインタビューでは
「どうみても日本人じゃない名前が入力されてた」
と証言してたなΩ
「誤入力」のせいで支給額が数万円減ってる人がいるそうだが
中国人口座に年金流出してないか
これあかんやろ Ruby on Rails Is Dead — 2018 Edition – JetRuby
http://b.hatena.ne.jp/entry/s/expertise.jetruby.com/is-ruby-on-rails-dead-2018-edition-407a618dab3a
DHH:Railsがあれこれやらない、というところですかね。Railsにはやらないと決めた機能ですとか、却下した余計な装飾品ですとか、そういうのがたくさんあるんですが、
Railsにある20%のソリューションで問題の80%を解決できるようにしています。
http://kdmsnr.com/translations/interview-with-dhh/ railsチュートリアルやってるんですが
実はRuby 1.9以降では、ハッシュの要素の順序が入力順と同じであることを保証していますが、ハッシュを特定の順序に依存してカウントするのは得策ではありません
という記述があり、なんで?ってなってます
ハッシュに順序性があるなら、それを利用して何が悪いのか? どんな偉い人が書いたものでも理由が書いてないものは
読み飛ばしていいってじいちゃんが言ってた >>602
そもそも、ハッシュは重複を許さない集合だから、順序は無い。
それを、ハッシュに追加した順番も、記録するようにしただけ
詳しくは、プログラム板のアルゴリズムのスレなどで、聞いてください >>605
それは知ってます。
Rubyが1.9は登録順が保証されてるのにそれに頼ってはいけない。 と記述されているようにみえるんですがなんで?と思ったんです。
実装されているなら利用して何が悪いです?
Ruby1.9未満に対する互換性とか? >>606
設計の筋が悪いから
実装してあるからといってinstance_variable_getを使いまくってるコードなんて気持ちわるいだろ? 筋悪いのはRubyの方だけどな。
拡張すればいいだけの話なのに、なぜか基本から変えてしまう。 >>608
何か基本から変えたっけ?
文字列の話ならPythonだってそうだし(おかげでPython2がまだ生き残ってる) >>607
筋が悪いかどうかは処理によると思います。ハッシュが順序性が無くてOrderdHashmapを実装する手間が無いのはありがたいと思いますが Rubyは登録順が保証されてるのだからそれを利用していい。
Perlなんか見てみろ。登録順が保証されない。
どうやっても保証されないとわからせるために
実行ごとに順番が変わるようになってる
便利さよりも、本質を学ぶならPerlだ
https://ja.wikipedia.org/wiki/Perl
> ハッシュの際に使われるシードがランダム化され、keys や
> values、each といったハッシュを利用する関数が返すキー/値の並び順が実行毎に異なるようになった。 >>606
現時点の特定の実装(CRuby)に依存した実装になることを理解した上で使えということ。
Hash から OrderedHash を派生させてそっちを使うようにしておけば、ソートされてることを期待していると言うことがソース上に明示できるし、将来仕様が変わったときに自分でソートして返すといったような対応もできる。 ハッシュの登録順が保証されるのは、特定の実装じゃなくてRubyの仕様だよ
Rubyの仕様に反する実装は実装側の問題で実装を修正すべき >>614
JISX3017 15.2.13.4.9 - 11
レシーバのそれぞれのキーと値の組について、処理系定義の順序で、 Hash は、現在の実装が、たまたま順序保証しているだけ。
もっと効率的な速い、アルゴリズムが見つかれば、変わる
単なるHash に、順序保証まで求めるのは、設計・筋が悪い
順序を保証したいなら、OrderedHash を使う
こちらは、順序を保証するのが目的だから、動作が変わることは無い
詳しくは、プログラム板のアルゴリズムのスレなどで、聞いてください >>615
古くてRubyの一部しか網羅してない中途半端な仕様がどうかしたの? >>617
> 順序を保証したいなら、OrderedHash を使う
はい、だからRubyはOrderedHashが使われています。
順序が保証されているわけですね。 django使ってみたけど、わかりづらいな
railsと違って自由度がある分、使いづらく感じた >>620
わかるわ。俺もレールの上に乗りたい
今PHPのLaravelと同時進行で勉強中だけどrailsの方が良さげかな
replの補完具合はrailsの方が上みたい。まだ序盤だからどう変わるかわからんけども YouTube の、full scratch で書く動画を見ているけど、
Node.js を、full scratch で書くよりも、
Ruby で、Sinatra を、full scratch で書く方がわかりやすい
Node.js + Express + Express Generator よりも、
Rails の方がわかりやすい
結論、Node.js の前に、
Sinatra を、full scratch で書いてから、Rails をやるのが良い >>620
なれると rails より django の方が良いわ 小規模なシステムを作るのはできるんだけど、ある程度の規模のをマルチプラットフォームで作ろうってときにどうやったらうまく作れるようになるのかね
どうしても行き当たりばったりになってしまって進まない マルチプラットフォームってこの場合どういう意味?
レスポンシブ対応のこと? rspec使っていて感じた違和感についての独り言
ベストプラクティスの中に、itの中のexampleは一つにしましょうってのがある
http://www.betterspecs.org/jp/#single
方向性としては否定はしないんだが、これができない場合がある。
それが何かっていうのにようやく気づいた。
一つは副作用があるメソッド。そもそも副作用は無くすべきだから
ないという前提に立てば、副作用に対するテストの回答がrspecに用意されてないのもわかる
itをそもそも特定の一つのsubjectへのexpectと考えれば、subject以外への変化
例えばファイルが作成されるとか、そういうsubject以外へのテストができない
(だから複数のexpectを使うことになってしまう)
もう一つはmock。doubleに対するexpect。これはメソッドを実行した結果でも副作用でもない。
内部実装に近いがメソッドの処理の中で行われる外部モジュールの呼び出し
it { is_expected.to ~ } みたいに書く所からの解釈で
まず処理実行 → 実行結果のテスト という流れなのだが、
mockを使った場合は、処理実行前に expectを書く必要がある。
普段実行結果が〜であることを期待して使ってるexpectとしては適切じゃない
ここからの結論として、itの中が複数になってしまうのは
・処理の中で行われることのテスト
・処理そのもののテスト(本質的なテストはこれ)
・副作用に対するテスト
この3つがうまく分離できてないからなんだ あー、説明面倒くさいからしないけど
一見関係なさそうに見えるけど一部は関係あるレベルか どうもGiven When Thenとrspecとの対応に違和感がある
contextにはしばしば、whenで始まる文章を書く
http://www.betterspecs.org/jp/#contexts
だがrspecと対応付けると
Given・・・context
When・・・it?subject?
Then・・・expect
となる。
どちらかが間違っているといいたいわけじゃない。
どちらも正しいと思うのだが、なぜwhenの使い方が違うのだろうか
○○という状態があって、DOした"時" (=when)
○○という状態の"時"(=when)
rspecではDO、つまりなにかを実行するというのが
subjectに埋め込まれてしまっていることか
実行までが状態になっている
そうか。rspecでは、(subjectを使った場合)Given - Then になってるんだな
subjectは遅延されて実行されるからといって、it もしくは subject参照時が
whenと考えてはいけないのか。遅延実行するのはあくまで内部実装の話だしな
Given - When - Then の方が俺的にはしっくりくるんだが、Whenというのは
通常一回しか実行せず、Givenの後と決まってるからGivenにくっつけても成り立つわけか。
(同様にThenの最初としてくっつけても成り立つんじゃないかな?それがitかな?) てすると実は正しい対応っていうのはこういうことなのかもしれない
Given・・・context(subject含む・subjectにWhenで実行する内容が定義されている)
When・・・なし
Then・・・expect(it含む・itでWhenで実行する内容を実際に実行する)
rspecでcontextでしばしばwhenで始めるのは、
なるほどそうか、subjectを実行したと仮定した内容を書いてあるはずだな
http://www.betterspecs.org/jp/#contexts を見直す
あー、やっぱりそうだ。contextそのものはGivenに相当するものなんだけど
contextにかかれているメッセージはWhenの内容だ。
で、もう一つ、contextにletで書いた内容と同じことを書く
つまりletでurl = error pageと書いてるのに、エラーページにアクスした時と
contextに書くのは重複していると思っていたが、そうか、
contextには、whenに続けて実行する内容を書くべきなんだ
つまりsubjectで実行することだな
Given When Then (GWT) も Arrange Act Assert (AAA) も
3段階なのに、なんでrspecは2段階になってしまったんだろうか?
状態を定義すると結果が確定する。間違いとは言わないんだけどね。
ちなみになServerspec、あれは状態を作るのを他でやるから
Thenのみになってると考えれば良いのだろう
subjectは存在するが、それは検査対象を明確にしているだけで
なにかを実行しているわけじゃない。
ってすると、subject(題材)という使い方は、それでよくて
subjectに含まれる、処理実行(Whenに相当するもの)を
subjectと分離すると、Given - When - Then の形になるかも でな、話は変わるけど、モック?スタブ?よくわからんけど
allow(モックオブジェクト).to receive(メソッド名) ってやるやつ
あれは、letかsubjectに入れちゃえばいいと思うんだよ。
だって、Givenに相当するものだろ?
だからitの中っておかしいと思うんだ
で、itの中はexpectだけにする
expect(モックオブジェクト).to receive(メソッド名) でもテストできるけど
それだとWhen実行前に書かないといけないので
expect(オブジェクト).to have_received(:メドッド名).once
こっちを使うべきなんだろうな
rspec-mocksのSpyという機能を使います
https://qiita.com/_am_/items/398b0782fa3754ff3878
そうすると、Given Then パターンだと
subject { allow(オブジェクト).to recieve(:メソッド) }
it 'ほにゃらら' do
is_expected.to なになに
expect(オブジェクト).to have_recieved(:メソッド)
end
という形になる。まあGivenの部分とThenの部分の両方で
同じようなコードを書く必要がるというデメリットはあるな
これはallowの方に名前をつけて、そのallowが呼ばれたことという形でかければ良いんじゃないかな? 例えばこんな感じ
subject { allow(オブジェクト).to recieve(:メソッド).named(’これ') }
it 'ほにゃらら' do
is_expected.to なになに
expect(これ).が呼ばれていること
// expect(これ).が2回呼ばれていること
// expect(これ).が呼ばれていないこと
end
こういう仕組みって有るのかな? >>633
expect(オブジェクト).to have_received(メソッド).twice
expect(オブジェクト).not_to have_received(メソッド) >>634
それは>>632で書いてあるとおりわかるんだよ
ただdryじゃないなってこと。
allowで書いたんだから、「それ」が呼ばれることって書くだけでいいじゃない? モデルはテーブルの行に対する対応だから単数形を使うというのは分かるんですが
コントローラは複数形を使うのは理由があるんですかね? >>636
名詞の形容詞的用法は単数形だからかな? >>637
その理屈だとコントローラも単数形になってしまわんですか? 開 2 ち ゃ ん ね る= 便 所 の 落 書 き ・ 痰 壷 の 更 に 劣 化 コ ピ ー の 3 流 掲 示 板
運 営 の 性 格 の 悪 い 引 き こ も り I T 土 方 メ ガ ネ ザ ル 早 く 死 な な い か な WindowsにROR入れるの大変すぎません?
エラー起き過ぎてストレスフリーで開発できない >>642
開発するためにWindowsを使うとか正気の沙汰じゃない、ありえん! WindowsならVM入れるかBash on Windows使うかDocker for windows使うかのどれかだな windowsでrubyは、お薦め出来ない
springの検知も遅いし、ていうか、使いもににならない?
私も頑張ってwinで構築して、やってられなくて諦めました gem入れるたびに動かないかもって思いながらやるあの苦行な
仮想環境がいい >>648
ほんそれ
動かないかもだけならまだましで
せっかく動いてるのに壊すかも
だし bundlerでも心配
gemのバージョン指定しても依存関係のあるgemで動かなくなることがある罠、そもそもgemが消えたり それはnpmでもpipでもmavenでも一緒だわな npmでも超重要ライブラリが作者の運営への不満から削除されて一時大パニックになってたな Windows10 + Vagrant でやろうかと思ったんだけど、これってもしかしてWSLで事足りる?
WSL使ったことないけどどうなんだろう Rails勉強中の20歳です
少し聞きたいんですが、どのくらいRailsができたら転職してもいいラインですか?
あるいは、エンジニアとして一人前? >>656
rails 用の gem を作って公開して、第3者の商用システムで採用されるレベルのちょい下位なら。
後は rails 以外の知識と経験。 >>656
rpecでテスト書けるならいい感じだよ、できれば、turnupも >>656
その質問を他人に聞きたいと思っている間は、たぶんダメだと思う。 railsを仕事で使ってる会社は大抵レールから外れた使い方してるから入門書とか殆ど約に立たないんだよな 入門書じゃ仕事にならない
↓
レールから外れる
↓
Rails使う意味なし
↓
Ruby使う意味なし >>661
レールから外れた使い方ってどうやるの? >>663
例えば複数のDBに接続していてdatabase.ymlにあたるものが複数あるとか >>663
次バージョン以降で追加される機能を既に自前で実装してるような状態。
結果的に複数の実践例ができてそのなかのいくつかの概念や実装が統合されて新しいレールになる。 実際の実装が知りたいの?
それこそ会社によって違うから知ったところで参考にならんよ 会社によって違うといっても
大抵レールから外れた使い方してるって
知ってるんですよね?
なんでそれを言えないんですか? >>668
社外秘に触れるかもしれないし、内容で所属組織が分かる。公開情報なら slideshare や speakerdeck 見たほうが速いし詳しい。 へぇー、社外秘に含まれるかもしれないのに
なんで他社が大抵レールから外れた使い方をしてるって
知ってるんですかねぇw >>670
そりゃあ技術者同士は横で繋がってるし、キモの部分の技術交換はこんな掲示板でやらないからねえ。
提供する技術すら持ってない人には難しい話かもしれないね。 >>672
横の繋がりを持つ技術者たちはRailsをいかにうまく使うかノウハウ交換してるからね
レールに乗れないからRails要らねRuby要らねとか愚痴吐くしかできない人には難しい話かもしれないね ■ このスレッドは過去ログ倉庫に格納されています