【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の実装は後者
前者はすぐに破綻する 大抵のWebアプリケーションは読み込みと書き込みの比率が10：1程度だから
書き込み時に大きい負荷を持っていって、読み込み時は閲覧用に高速に取得できるように組み立てておいたデータを表示するのは
よくある設計だな
NoSQLなら正規化しないし >>55
アカウント作って放置みたいな捨てアカウントにまでファンアウトしまくるのか？
どっちみち後者の方が破綻するのが速いのが目に見えてる たぶん、更新用・参照用の表は、別々
更新してしばらくすると、参照用の表に、コピーされる 更新と参照が別なのは分かるけどしばらくして同期取るのだとサービスに影響出まくると思う ウィリアム氏がOdeo内で始めた小さなプロジェクトが「Twitter」だ。
Ruby on Railsを使って2週間で最初の動くバージョンを 作り上げた
http://www.atmarkit.co.jp/news/200711/16/twitter.html 何台も浪費するようなサービスが最初から作れるとでも思ってるのかね vCPU ECU メモリ（GiB） インスタンスストレージ（GB） Linux/UNIX 料金
x1.32xlarge 128 349 1952 2 x 1920 SSD $13.338 /1 時間
https://aws.amazon.com/jp/ec2/pricing/on-demand/
CPU20コア、メモリ224GBまで選べる仮想サーバー。
http://cloud.sakura.ad.jp/specification/server-disk/#server-disk-content01-price ドワンゴ、「ニコニコ動画」のストレージにSun ZFS Storage Applianceを採用
単一ボリュームで250テラバイト以上の容量を構築できる拡張性などが評価されたという。
http://www.itmedia.co.jp/enterprise/articles/1108/22/news061.html 1.9テラバイトメモリ、Xeon4基64コアの大型インスタンス「X1.32xlarge」登場、ハードウェアトランザクションメモリにも対応。Amazonクラウド − Publickey
http://www.publickey1.jp/blog/16/19xeon464x132xlargeamazon.html AWSのS3に、500PBのデータを保存していた、Dropboxが、独自のインフラに移行したらしい >>65
成功してから作り直すの？ハア？
それにLL言語なら今ならPHP7のほうが良くないかな？ 実際にFacebookやMySpceやYoutubeみたいなスタートアップを作れる確率は飛行機で事故が起きる確率と同じくらい超低い
http://www.turnyourideasintoreality.com/2014/02/dhh/ マイクロサービスの終焉 | 開発手法・プロジェクト管理 | POSTD
http://postd.cc/the-end-of-microservices/
マイクロサービスの強み弱み
マイクロサービスには分散システムとしての複雑さがあり、注意しなければならない課題がある。
例えば、“ネットワークの遅延や耐障害性、メッセージのシリアライゼーション、
信頼できないネットワーク、非同期性、バージョニング、アプリケーションの各層に対するロードなど”だ。
http://www.infoq.com/jp/news/2014/06/microservices
コンピュータにおいて、制御を行う要素の数が1個の場合、2個の場合に比べて3個以上の場合で複雑さは段違いに異なる。
http://anond.hatelabo.jp/20130319023155
太陽と地球のような二体問題は厳密に解けるが、例えば月の運動も考える一般の三体問題以上になると解析的に解くことはできないとされる
http://ja.wikipedia.org/wiki/多体問題 >>72
だからといって最初から成功しない、絶対にスケールアウトしない前提でRoR決め打ちするのもどうかと思うけどな
学習コストなんてたかが知れてるのだから最初からスケールが容易なシステム上で開発するのが頭のいい人の行動だと思う >>76
プログラミングの世界にも似たような格言があるだろ
「必要になるかもしれない機能は実装するな、必要な機能だけ実装しろ」とな
そういう過剰な先回り思想は無駄になることがほとんどなんだよね スケールアウトのしやすさは機能じゃなくね？
アプリケーション側じゃなくインフラ側だし
デプロイ含めた運用のしやすさのほうに関係してる >>80
先回り思想としては一緒でしょ
スケールアウトなんて人気が出てから考えればいいのさ
どうせその頃にはあちこちガタが来て抜本的改良を考える頃だろうし Railsアプリケーションを、Heroku上で1分間125,000リクエストに対応できるようにスケーリングする | インフラ・ミドルウェア | POSTD
http://postd.cc/scaling-rails-to-125-000-requests-per-minute-on-heroku/ 最初から表現力があってスケールする言語で書けばいいじゃん
つまりJava
なんでわざわざRuby? >>84
Ruby 落として何が出てくるかと思えば Java ですか…ｗ >>85
ふつーにrubyよりもマシな言語じゃね？ >>86
Javaに表現力があると思ってる時点でお察し これ確実に、rubyはlispっ(ﾊｱ?)とか、メタプロラミングっ(ﾊｱ?)とか、イキがっている雑魚なんだろうなあ >>84
よりによってJavaかよ
煽りにしてはつまんないし、本気だとしたら救いようがないバカと思われるだけだぞ JavaはOracleったから無理だな
Javaに行くくらいならGolangにいくわ Railsでソートできるテーブルを作りたいんだけど
みんなどうやってるの？ 【宇宙】ルビーやサファイアの雲が存在？
地球から1000光年先の惑星、英大学が調査
da i ly.2ch.net/test/read.cgi/ne wsplus/1481704596/ ■ このスレッドは過去ログ倉庫に格納されています
