アカウント名:
パスワード:
そこを、蓄積されていく社内ノウハウを詰め込んだ社内フレームワークで賄うのもいいけど、 それだと人集めや教育、メンテで余計なコストが発生するのでフレームワークに飛びつきたい というのが全てのフレームワークに共通している潜在的な需要で、LLだから要らないとはならない。
ひがさんも同じようなことを言われていたと思うのですが、実際に社内フレームワークをどこの会社も使わなくなってきているのでしょうか？ 某社の場合、今だに社内フレームワークに固執しており、またオープンソースを使うことは堅く拒否し
Java言語そのものより、大規模なウォーターフォールで資料の作成等や面倒な手続き等が問題になってるだけだと思いますけど。 Javaでも軽い開発はいくらでも出来る。 言語を差し替えても何の効果もありゃしませんよ。
Javaの方が、Rubyより、定型的なコードが多く必要だってことは間違いないところじゃないかな。JavaのIDEには、コード補完の機能がこれでもかと入っているわけですが、定型的なコードを大量に書かなければならないから、そこを改善すると利用者の「効率あがった感」が高いので注力されているのだと思うのですが、違うかな。
言語を差し替えても何の効果もありゃしないのであれば、Java言語仕様のバージョンアップも何の効果もないはずでは？
# 個人的にはクロージャや高階関数のない言語では仕事したくないね。してるけど。
「何の効果もない」というのが「全体に与える影響が少ない」に後退したと読みましたが、それでいいですか？
ついでにいうと「プログラミングを手っ取り早く済ませられる」かどうかがRubyの評価につながっているわけではないと思います。「楽しく」プログラミングできることが重視されていることが、Rubyが評価されている理由だと思います。そしてモチベーションがプロジェクトの成功率を左右すると考えている人々が、Rubyを支持しているということだと僕は理解しています。
# もっとも、それでもJavaが負ってきた責任のすべてをRubyに任せられるとは思っていませんが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
RubyとRailsを切り離せ (スコア:2, すばらしい洞察)
以前誰かが書いてたが、
あのGoogleがNice Hackだからといって授賞したのがRailsだ。
つまり下々の企業じゃなくHackerがうじゃうじゃ居るような企業にとってNiceだということだ。
ヘタな奴がヘタに使うと危険。逆効果に成りかねない。
(これはRailsではなく誤解する人々が悪いだけだが。)
次。Rails(で作ったアプリ)って
書籍のサンプルレベルですら「コードが綺麗じゃない」のだよね。
綺麗といっても別にJavaのごとく書いてくれという意味ではなく、
なんというかRailsアプリのそれは、
字面がごちゃごちゃしてるんだ。
念のため言うけどそれはRubyの性質ではなく、Rails固有の性質のようだ。
つまりRailsで作ったコードは「Rubyらしくない」。
個々の道具である例えばActiveXxxxを使ったコードが汚いわけではないのだが、
なぜかRails全体で見るとゴチャゴチャになる。これは不味い。
あと良し悪しはともかく気になる点が、
Railsはアーキテクチャには何ら新しい工夫が無いって点だ。
コードが短くなるのは良いことだが、それでも所詮はMVC2だ。
その(利点もだが)欠点もそのまま無批判に輸入してしまってる。
ここは一応警戒しておいたほうが良い点であろう。
＃WicketのようにアンチMVC2、あるいは新SeasarのようにMVCっぽさをボカす、という手も有るのよ＞Webアーキテクチャ
さて。
Railsに決定的に不味い点あるいは不幸な点があるとすれば、
それは「一人勝ち」状態だという点だ。
ライバル不在なのだ。
もっとマシ(例えば下々がハマリにくいとか綺麗に書けるとか)
になるための競争が起きていない。
少なくとも登場してブレイクして以来ここ数年はそうだ。
そのためRailsが「進化の袋小路」に陥ってしまってる恐れが有るし、
もし陥ってしまっていても、
その欠点を速やかにアゲつらうための「比較対象」が居ない。
同じくライバル不在としてはMS謹製の各種フレームワークが有るが、MSは伝染力が元々最強なので、ヘマをやってもMSが失うものが少ない。RailsがコケたらRubyコミュ全体が不安だという構図とは一緒にならん。そういう意味では「フルスタック」も良し悪しだ。
これはRubyコミュニティ全般にとって不幸なことだ。
Matz氏も「流行るかどうかは気にしない」と言っているが、
それは流行曲線が平坦または上り坂だった時の話かも知れない。
もし下り坂になってもRubyを維持する気力が彼から沸いてくるか、
あるいは彼を支援する企業つまり氏の収入が維持されるか、は、
十分心配すべき事柄だ。
個人的にはRubyのファンなので、
彼(Mongrelの作者かよ！！)に「Rubyが」見捨てられるのは忍びない。
(Railsは比較的どうでもいいけどな。というかRailsバブルが弾けるときにRubyを道連れにしないでくれ。)
だから、
Railsに対抗するようなWebアプリフレームワークがRuby上に沸いて出てくれることを
強く祈っている。
しかも可及的速やかにね。たぶん勝負は年内だろう…
あるいはだ。
俺様の気が変わって或る日フレームワークを作ったならば、
藻前ら総出でそれを崇め奉れ！
それでこの問題は解決するぞ！:-)
＃作るまでは名乗る気がないのでAC
Re:RubyとRailsを切り離せ (スコア:1, 参考になる)
という前提ならかなり敷居が低い部類かと。
が、細かいことを考え出すとハマる。
例えば、Ajaxのリクエストでチャッタリング起こしてて、溜まっている
キュー捨てらんないのか? ちゃんと設定すれば対応できるのかもしれない
けど、その調べものに余計な時間かけてなお解決せず挫折。
なにが高速開発だ、ｳｷｰ…ってな具合。
結局RoRとグッバイして自前で作り直しましたとも、えぇ。
Re: (スコア:0)
LLを使う動機が丸つぶれな気がしてならないんだけど・・・。
# 楽しくねーじゃん
Re: (スコア:0)
何でAjax使った位で、サービス名に「Beta」ってつけなければいけないの？と同じ事（ウソ）
ていうかLLだから、フレームワークとは無縁と考えられるのは経験不足としか思えない。
マジレスすれば、大げさなシステムを仕事で作っていれば定型的手順を繰り返し作る事になる。
そこを、蓄積されていく社内ノウハウを詰め込んだ社内フレームワークで賄うのもいいけど、
それだと人集めや教育、メンテで余計なコストが発生するのでフレームワークに飛びつきたい
というのが全てのフレームワークに共通している潜在的な需要で、LLだから要らないと
Re: (スコア:0)
>世間の会社の企みとは乖離していて、たかが知れているという事ですよね。
それは逆だろう。
むしろ企業のほうが高が知れてるんだ、「LLの使い方」においては。
全部ではないが典型的企業(の中の人)においては、
LLのよさを活かす使い方なんて、思いもつかないものだ。
硬い開発体制を取れば安泰、そうでなければ死、と信じて疑ってない。
味噌はそこではない。
１つの案件が有るとして、その案件が軽いか重いか、の判断が、
(優秀な)個人と企業とでズレてるのだろう。
優秀な個人ならばだが、彼らは同じ仕事でも「軽い」と判断する(という率が高い)はずだ。
LLなりなんなりといった美味しい道具を美味しく駆使して、
案件を「軽くして」しまうことが出来る。
で、その優秀な人についていけないのが、(普通の)企業のレベル。
同じ案件でも重く評価してしまい、重い開発体制にしなければならないと判断してしまう。
Re: (スコア:0)
そこを、蓄積されていく社内ノウハウを詰め込んだ社内フレームワークで賄うのもいいけど、 それだと人集めや教育、メンテで余計なコストが発生するのでフレームワークに飛びつきたい というのが全てのフレームワークに共通している潜在的な需要で、LLだから要らないとはならない。
ひがさんも同じようなことを言われていたと思うのですが、実際に社内フレームワークをどこの会社も使わなくなってきているのでしょうか？
某社の場合、今だに社内フレームワークに固執しており、またオープンソースを使うことは堅く拒否し
Re:RubyとRailsを切り離せ (スコア:1)
まあ、突き詰めていえばそんなことが可能な企業なんて、今や全然思いつきませんけどね。
そもそも、CPUベンダとOSベンダを兼営しているところが数えるほどしかない。
一部大手メーカーの携帯電話はそんな感じかもしれませんが。
Re: (スコア:0)
フレームワークなんざ出番が無い。出番があるとしたらJavaのやつ。
1000万オーバーのプロジェクトだとLLの出番なんて補助的なツールとか
だけだもんなぁ・・・。
そういう意味では、必要と思ってる人は「実務経験」が不足してるんで無い？
Re: (スコア:0)
億くらいまではLLの案件なんていくらでもあるって。
ここ五年はもっぱらLLを使っているが、Rubyで1000万、Perlで5000万、PHPで7000万くらいまではある。
Re:RubyとRailsを切り離せ (スコア:1)
すでに億を突破しているそうですけど。
Re: (スコア:0)
Re: (スコア:0)
LLで(やれるものなら)やりたいという願望は、
十分理解できると思う。
大規模な仕事だったらJavaでやります、とか言っちゃったらちっとも楽しくないわけ。
そして、いわゆる「こまかいところまで弄くれる性質」は、
非LLからLLに換えたところで、
別に言うほど損なわれるわけじゃない、
というのは我々プログラマは(直感的にだが)知っている。
…まあこの直感的ってのが急所でもあるんだけどね。
つまり、実績というか「実際にやってみて確認した事例」がまだ少ない。
実は出来ないのかも知れない。
出来るかも知れないけどやりかたを少々変えないとならないのかも知れない。
だけどまだ
Re: (スコア:0)
Java言語そのものより、大規模なウォーターフォールで資料の作成等や面倒な手続き等が問題になってるだけだと思いますけど。
Javaでも軽い開発はいくらでも出来る。
言語を差し替えても何の効果もありゃしませんよ。
Re:RubyとRailsを切り離せ (スコア:2)
ということを主張しているように読める。それってトートロジーじゃないの?
Re: (スコア:0)
俺、関係ない人だけど、
> "Java がボトルネックではない状況ならば、Java を排除してもスループットは上がらない"
> ということを主張しているように読める。それってトートロジーじゃないの?
「A が原因でない状況ならば、A を排除しても意味がない。」の場合に、
どこがどこでトートロジーになってるの？
# いや、あたりまえにきこえたんでさ
Re:RubyとRailsを切り離せ (スコア:1)
「ボトルネック」と「スループット」はコテコテのこの辺の用語だから、
説明するまでもないかな、と思ったんだけど、確かに知らない人には
通じない書き方だった。
Re: (スコア:0)
リンク先を読んでもわかりませんでした。
リンク先の、この辺に注目したのですが、
> ボトルネックプロセスにおけるスループット(生産率)の増大によってのみ、全体的なスループットの増大が可能になる。
ボトルネックではないプロセスを改善しても、スループットは向上しない様に読めます。
多分、注目する箇所がなにか違っているのだと思いますが、
どの部分がどの様に繋がってトートロジーになるんでしょうか？
Re:RubyとRailsを切り離せ (スコア:1)
Javaの方が、Rubyより、定型的なコードが多く必要だってことは間違いないところじゃないかな。JavaのIDEには、コード補完の機能がこれでもかと入っているわけですが、定型的なコードを大量に書かなければならないから、そこを改善すると利用者の「効率あがった感」が高いので注力されているのだと思うのですが、違うかな。
言語を差し替えても何の効果もありゃしないのであれば、Java言語仕様のバージョンアップも何の効果もないはずでは？
# 個人的にはクロージャや高階関数のない言語では仕事したくないね。してるけど。
Re:RubyとRailsを切り離せ (スコア:1, 興味深い)
逆に、開発作業におけるプログラミングの割合を大きくすれば、言語やライブラリの違いが大きく効いてくることになりますし、適切な言語・ライブラリを選択することで楽な開発にすることが可能になるのです。
Re:RubyとRailsを切り離せ (スコア:1)
「何の効果もない」というのが「全体に与える影響が少ない」に後退したと読みましたが、それでいいですか？
ついでにいうと「プログラミングを手っ取り早く済ませられる」かどうかがRubyの評価につながっているわけではないと思います。「楽しく」プログラミングできることが重視されていることが、Rubyが評価されている理由だと思います。そしてモチベーションがプロジェクトの成功率を左右すると考えている人々が、Rubyを支持しているということだと僕は理解しています。
# もっとも、それでもJavaが負ってきた責任のすべてをRubyに任せられるとは思っていませんが。
Re: (スコア:0)
＃最近自分がやってて楽しいと思った仕事はP2Pネットワーク内にオブジェクト流して
＃分散処理ってやつだけど、Java使った。