【RoR】Ruby on Rails Part20©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>540
というかそこまでのアクセスを見込むんだったら、自分たちで技術調査をして負荷確認をして、とかやらないとね
それをこんなとこで聞いてしまうレベルだとどんなFW使っても炎上すると思うよ 今、巷で話題になってる質問箱ってサービスも
Railsらしいよ >>541
リクエスト当たりの収益が全然上がらなくて、APサーバの数は増える一方。
付帯する管理コスト、業務コストだけはグングン増えていつかは"慎重な検討の結果、本サービスを終了する事となりました"。
>>542
そう。
こんな程度のことも調査・検討しないでRoRはオワコン、今は○○とか言う人は何選んでも成果出ないとおもう。 >>545
PHPでRailsっぽいのってCakePHP？ ぺじーは知らんけど、ルビーとバイチョンの違いなら >>2 に書いてあるよ 誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
7WXCJUAQT8 GitHub - stimulusjs/stimulus: A modest JavaScript framework that works with the HTML you already ...
https://github.com/stimulusjs/stimulus ミニブログの Twitterのstats(統計)データ。
http://kaworu.jpn.org/kaworu/2008-01-16-2.php
- 350,000を超えるユーザ。
- 秒間600リクエスト
- 平均毎秒200-300コネクション。最大時は秒間800コネクション
- MySQLは秒間2,400リクエストを処理する
- 180のRailsインスタンスがある。MongrelのWebサーバを使っている。
- 1つのMySQLサーバ(１つの大きな 8コアのサーバ)と１つのスレーブ。スレーブは、統計とレポートのための読み込み専用(リードオンリー)。
- 雑用処理をするための30+のプロセス
- 8台のSun X4100s
- Railsでのリクエストの処理時間は200 msec
- データベースにかかる時間の平均は、50-100 msec
- 16GBの memcached Dockerの本番運用 | インフラ・ミドルウェア | POSTD
Dockerを真剣に使い、成功し、さらに多くのトラブルに遭遇することもなかった人を、
私は世界中で一人も見つけることができませんでした。
この記事で書かれている経験談は、社員と企業がダウンタイム一秒毎に11万円を損失するという犠牲の上に得られたものです。
過去の教訓から同じ過ちが繰り返されないことを望んでいます。
http://postd.cc/docker-in-production-an-update/ Docker in Production: An Update | Hacker News
https://news.ycombinator.com/item?id=13713788 Microserviceなんて最初からやるもんじゃ無かった
http://www.slideshare.net/AkiraMiki/20160722-microservice
マイクロサービスの終焉 | 開発手法・プロジェクト管理 | POSTD
http://postd.cc/the-end-of-microservices/
【翻訳】モノリシックなRubyからGoによるマイクロサービスへ | POSTD
http://postd.cc/from-a-ruby-monolith-to-microservices-in-go/
マイクロサービスの強み弱み
マイクロサービスには分散システムとしての複雑さがあり、注意しなければならない課題がある。
例えば、“ネットワークの遅延や耐障害性、メッセージのシリアライゼーション、
信頼できないネットワーク、非同期性、バージョニング、アプリケーションの各層に対するロードなど”だ。
http://www.infoq.com/jp/news/2014/06/microservices
コンピュータにおいて、制御を行う要素の数が1個の場合、2個の場合に比べて3個以上の場合で複雑さは段違いに異なる。
http://anond.hatelabo.jp/20130319023155
太陽と地球のような二体問題は厳密に解けるが、例えば月の運動も考える一般の三体問題以上になると解析的に解くことはできないとされる
http://ja.wikipedia.org/wiki/多体問題 MySQLからPostgresqlにシステムが移行したんだけどログファイルに出されるSQLが、
select * from users where name = "hoge"
だったのが
select * from users where name = ? [["name"]["hoge"]]
みたいな奇妙なプレースホルダー形式になってしまった。
元の形式のSQLをコピペして、SQLコンソールで実行することがしばしばあったんで色々不都合なんだけど、元の形式で出す方法ってないかな？
(後者のは当然、シンタックスエラーになる...) 私が億万長者になった日
Ruby on Railsの生みの親が見つけた人生で「最良のもの」
By DHH
https://medium.com/japan/4614d3f4a255
考え直そうーーRuby on Rails生みの親でBasecampの創業者がスタートアップに贈る言葉【寄稿】
http://thebridge.jp/2016/04/reconsider
DHH:Railsがあれこれやらない、というところですかね。Railsにはやらないと決めた機能ですとか、却下した余計な装飾品ですとか、そういうのがたくさんあるんですが、
Railsにある20%のソリューションで問題の80%を解決できるようにしています。
http://kdmsnr.com/translations/interview-with-dhh/ @project = Project.find(params[:id])
Webアプリケーションによってはこのコードでも問題はありませんが、そのユーザーがすべてのビューを参照する権限がない場合には問題となります。
このユーザーがURLのidを42に変更し、本来のidでは表示できないページを表示できてしまいます。
このようなことにならないよう、 ユーザーのアクセス権もクエリに含めてください 。
@project = @current_user.projects.find(params[:id])
https://railsguides.jp/security.html#権限昇格 ActionCableでDeviseのcurrent_userを扱うにはどうすればいいですか？ 2017年度 未踏成果報告会「MITOU2017 Demo Day」1日目
2018/02/10(土) 開場:09:57 開演:10:00
e/lv310182883 これから勉強するんですが初心者にオススメの
参考書とかサイトあります？ 「10倍プログラマ」の神話、Ruby on Railsの生みの親が語った高い生産性のカギとは!?
http://hrnabi.com/2015/01/30/5463/ >>570
改訂3版 基礎 Ruby on Rails、黒田努・佐藤和人、2015
実践Ruby on Rails 4: 現場のプロから学ぶ本格Webプログラミング、黒田努、2014
黒田の本は、わかりやすい。
ただし、他の著者で、Rails 5 の本も出ているかも Railsはビュー周りがダメだな
なぜフォームヘルパーなどという腐ったものを作り出したのか？
普通にHTMLを書けばいいじゃないか そういう問題じゃないんだけどねｗ
よく知られた方法があるのだから
それを使いましょうと
フォームなんか
<form name="model[name]" 略
でいいじゃんかと
なんでそれをわざわざRubyのコードに置き換えるのかと 日本だと、10万円/1か月ぐらいのRoR案件もあんぞｗ あれって 中間が抜いてるせいなのかね？ 元々が安いのかね？ >>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
その理屈だとコントローラも単数形になってしまわんですか？ 開 ２ ち ゃ ん ね る＝ 便 所 の 落 書 き ・ 痰 壷 の 更 に 劣 化 コ ピ ー の ３ 流 掲 示 板
運 営 の 性 格 の 悪 い 引 き こ も り I T 土 方 メ ガ ネ ザ ル 早 く 死 な な い か な ■ このスレッドは過去ログ倉庫に格納されています
