【RoR】Ruby on Rails Part20©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Ruby がなければ、とか Rails さえ登場しなければ、と考える人達は
昔から存在していた
・Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1
http://anond.hatelabo.jp/20120118220204
> 48 : デフォルトの名無しさん : 2011/11/13(日) 08:30:25.68
> 44
> Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
> さかんに宣伝され、雑誌でもZope特集が組まれていた
> 少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
> そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
> 今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
> djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
> しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
> Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
> 何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
> Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
> だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている 脱Railsに誘導する勢力が増えてきたのは会社都合なのかね
今後、自社に入ってくるかもしれない新米エンジニア候補に
間違った道を選んでほしくないからやってるんだろうけど
それは教育コストかけて社内でやるべき Rubyの文法つかってバイナリ吐き出す高速なクリスタル言語よくない？ クラウドワークスのエンジニアの若手を潰すとかいう下衆発言といい
rails界隈って露悪的でエグみが強いやつらが幅をきかせている残念な印象
技術力はしらん。どうせ大したことないだろ >>14
いやいや分散しないほうがいいでしょ
【Erlang】プログラム言語 Elixir 【BEAM】 [転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1433336300/ >>17
ブラックなIT土方代表のJava、PHP様たちには到底かないませんけどね >>20
うんこと腐ったミソと普通のミソがあるとしたら
railsは腐ったミソだな プログラミングElixir、2016
Ruby界隈から、名著が出た。
著者は「プログラミングRuby」のDave Thomas
関数型言語Elixirは、Ruby + Rails + ErlangVM で、並行処理が得意 Linux API を、Windows API に変換するので、Ubuntu64 のバイナリがそのまま動く、
Windows Subsystem for Linux (WSL) で、Railsが動くという書き込みが、プログラム板にあった
apt-get で、パッケージもインストールできる
日本語も使える端末、ConEmu。
GUI表示用のXサーバー、Xming X Server for Windows
人柱、キボンヌ rails 4.1 でバッチプログラムを作りたいんだが、
コントローラーは app/controller でもへんじゃない？ フリーのサイトテンプレート落としてきてrailsで使おうとするとassetで積みがちなのは普通？
mixitupってのが動作しなくて格闘してるんだがjQuery周りが動くのとそうでないのと混在してて不便･･･ そりゃrailsは時代遅れだから徐々に腐ってきてるんだよ decoratorとhelperの用途の違いって何なんだ？
役割としては同じだけど様々なViewで横断的に使うメソッドかどうかで使い分けるって認識で良い？ decorator: 特定controller-viewのpresentation層
helper: 特定でないcontroller-viewのユーティリティメソッド集
こういう認識だが railsって本当に終わったの？
今でも起用してる大手とかあるん？ >>36
じゃあだいたい合ってんのかな
ありがとう ク○ウドワー○スと○ック○ッド以外でrailsにこだわっているところってまだ存在するの？ QiitaとかもRailsじゃなかったっけ
使ってるところなんかたくさんあるだろ ほとんどが惰性で使って運用で常時苦しんでそうなイメージ Scalaで置き換えると楽になりますってのが流行ったな Twitter が使ってたからだろうね
そしてやっぱり苦労する、という
銀の弾丸なんてないのに フォロワーが数百万人もいる有名人がTweetする度に
そのフォロワーたちのタイムラインに対して、合計数百万回の書き込みをしなければいけないことを知って愕然とした
（この処理をTwitter社内ではFan outと呼んでいた）
こんな仕様じゃマシンリソース食いまくって大変だろう
Rubyでやるのは狂気の沙汰だし、Scalaで書き換えてもDBに対するIOなので期待するほど早くならないし… >>48
そんなアホなことしてたん？
設計ミスやろ
普通はタイムライン見るときにアクセスすれば済むだろ http://www.atmarkit.co.jp/news/201004/19/twitter.html
http://www.atmarkit.co.jp/news/201004/19/twitter05.png
＞ 上のようなストレートな実装では、フォロワー数が増えていくると途端にスケールしなくなる。
＞メモリに載り切らずにディスクアクセスが発生し、レスポンスが落ちるためだ。
＞ディスクアクセスのペナルティは大きく、1秒以下で終わるはずのページの描画が数秒かかるということになる。
＞そして1つのつぶやきは平均600個もfan outされるため、秒間120万のメッセージ配送を処理する能力が求められるという計算だ。 DBの正規化では、1-fact, 1-place
DBでは、データの複製を持ったりしない。
レプリカ・キャッシュを作ることはあるけど 多対多の結合テーブル参照してIDリスト取得、そのIDリストの件数分、Tweetテーブルにアクセス
フォロー人数が10万人なら10万回
1対多の自分専用Timelineテーブルにアクセス
フォロー人数が10万人でも1回で済む
Twitterの実装は後者
前者はすぐに破綻する ■ このスレッドは過去ログ倉庫に格納されています
