09/07/26 04:16:25
2.0 への思い入れ云々を除いても、バージョン1をバージョン2に上げるほどの何某があるとは思えん
1.9.1 の次くらいを 2.0 にするならまあアリかなと思う
1.9.1p0 の存在が鬱陶しいと思ってる人は少なくないはずだよ
374:デフォルトの名無しさん
09/07/26 04:27:31
1.9.1 は本体オンリーはともかく第三者ライブラリ全体を含んだ便利度はまだまだだなー、と感じるわけだが、
これが 2.0 だった場合は「バージョン 2.0 とか言ってる割には全然…」だの
「2.0 はアレなので 2.0.4 以降インストールしてください」だのいうことになったと思う
今現在我々が 1.9.1 の使い勝手に抱いている感想は、
それのバージョンが 2.0 だったからといっていい方向に作用したと思われるものではない、はず
375:デフォルトの名無しさん
09/07/26 11:15:43
URLﾘﾝｸ(d.hatena.ne.jp)
ヒドスwww
376:デフォルトの名無しさん
09/07/26 16:42:35
ささぴーひっどーぉい。（か☆わ★い☆い★女☆子★高☆生 より
377:デフォルトの名無しさん
09/07/26 17:06:50
うわぁ
378:デフォルトの名無しさん
09/07/26 19:52:21
おいtrunkのrakeやrdocやrubygemsは最新版にアップデートしないのか
379:デフォルトの名無しさん
09/07/26 20:11:05
ruby-coreでいえ
380:デフォルトの名無しさん
09/07/26 21:03:56
アップデートしてくれる度にtest-allのエラー数が激増するんで困ってる
381:デフォルトの名無しさん
09/07/27 11:34:32
> Google App EngineではJRails on Rubyも動いてます。
> もうJVMでいいじゃんっていうことになる危機感は？
ここはまつもとさんじゃなく、
ささださんの回答が見たかった。
382:デフォルトの名無しさん
09/07/27 13:42:39
bigtableは独特だからなぁ
383:デフォルトの名無しさん
09/07/27 14:31:58
ここに書けばささださんの回答は得られる
384:デフォルトの名無しさん
09/07/27 14:59:14
Rails で web アプリケーションをやろうとしていて、
1.9 系はまだ使いたくないという場合は、1.8.7 を選んでおけばいいのでしょうか？
385:デフォルトの名無しさん
09/07/27 15:02:50
あい
「一般ユーザー」でRuby1.9を現在使うメリットとデメリットを均すとマイナスになります
エラーの意味も原因もさっぱりわからん直せと言われてもさっぱり、な人はしばらく 1.8.7 で待機しましょう
386:デフォルトの名無しさん
09/07/27 15:16:21
自力で改修くらいできるぜﾋｬｯﾊｰという人はガンガン 1.9.1 を使って欲しいところ
汎用性があったらライブラリ作者に連絡でもしてくれ
387:デフォルトの名無しさん
09/07/27 15:19:38
そんな人が何人いるんだよ…
388:デフォルトの名無しさん
09/07/27 15:47:28
改修くらいはできるけど
あえて1.9.1以降を、自分から積極的に使う意欲はわかない
389:デフォルトの名無しさん
09/07/27 15:48:51
github になったら commit する人とか少し出るかも
390:デフォルトの名無しさん
09/07/27 17:22:17
ちょっとだけ違う野良フォーク祭りになるだけのような気がしなくもないが、
ブログとかに差分がちょこっと書かれてるだけとかいうのよりは遥かにマシか
391:デフォルトの名無しさん
09/07/27 18:06:17
なにをどうすれば pull request に足るものなのかよくわかんないんだよね
だったら自分専用でいっかーみたいな
392:デフォルトの名無しさん
09/07/27 18:08:36
そういう混沌状態を意図してるのでないの？
思いっきりforkやcommitの敷居を下げることでさ
393:デフォルトの名無しさん
09/07/27 19:12:31
パッチが欲しいからgithubに行くと言ってる人がいるとするならば、
その日とは「なんでもいいからpull requestしろや、俺が全部
さばいてやるぜ」というつもりで言ってるんだよね？
394:デフォルトの名無しさん
09/07/27 19:46:47
githubになったって、そこ巡回してpullするリソースがないよ。
現状、Redmineに上がっているパッチだって取り込まれるのに時間かかってるのに。
あと、そんなパッチもtypoの修正ならともかく、たいていはそのままじゃ取り込めない。
395:デフォルトの名無しさん
09/07/27 21:20:40
じゃあ、githubに移行するという話は根拠のないデマなの？
396:デフォルトの名無しさん
09/07/27 21:24:00
githubに移行して欲しいと言う人たちはいる。
また、githubに公式リポジトリのミラーを置く計画はある、こちらはyuguiさんのリソース次第
397:デフォルトの名無しさん
09/07/27 21:25:43
とはいえ、今より敷居が下がるのはいいことだとおもうけどね
なんか今だと関連MLの記事を数年分把握してて、
主要コミッタとのリアルつきあいも欠かさず行って、
一日の何時間かをRubyに捧げる宣言しないとならなくて、
事情があっても辞めるに辞められないようなイメージがあるわw
398:デフォルトの名無しさん
09/07/27 21:59:12
>>397
それ全部満たしてる開発者いないだろｗ
399:デフォルトの名無しさん
09/07/27 22:39:26
WindowsのMingw版rubyを1.8.7にバージョンアップしたら
Thread.new{system 'ruby -e sleep(30)'}
が、負荷10数%食うようになってた orz
Mingw版 1.8.6 とか 1.9.1だとそんなことは無いし
Mswin版 1.8.7 で試しても問題なかったのでMingw版1.8.7だけなのかも
STDIN.getsがスレッドを止めなくなったとかの影響なんだろうか
とりあえず、ちょっとだけ待ってスレッドを殺すことにした
1.9だとspawn使えるんだけど
400:デフォルトの名無しさん
09/07/27 22:55:00
それはまつもとさんでもあやしいなぁ……ｗ
401:デフォルトの名無しさん
09/07/27 23:48:33
URLﾘﾝｸ(www.atmarkit.co.jp)
なにポーズつけてるんだよ（ｗ
402:デフォルトの名無しさん
09/07/27 23:51:46
これは三つ子と言われても普通に信じるレベル
403:デフォルトの名無しさん
09/07/27 23:58:35
yugui さんにしろ笹田さんにしろ、若いのにすごいなぁっておもった。
おれなんか33の業務系SEだけど、
Ruby にしてもほかの言語にしても、使う側で精一杯だよ。
こういう人たちは、「プログラミング言語オタク」でもあるんだろうな。
404:デフォルトの名無しさん
09/07/28 00:31:24
>>403
人のことを素直にすごいと思えるおまいさんはまだ伸びる素質がある。
なにかにつけ欠点を探して自分を優位にしておかないと気が済まない連中というのが少なからず存在して、
そういうやつは口ばっかり達者でいつまでたっても実力が身につかない。
405:403
09/07/28 01:39:13
>>404
どうもありがとう、コーディングする機会も減ってきたが、まだまだがんばるよ。
406:デフォルトの名無しさん
09/07/28 02:17:08
>>404
でも、いろんな人やら意見を懐疑的に捉えて自分なりに
いろいろ考えるのも楽しいお。
盲目的に「すげー」はかえって学ぶ機会を損失するとおも。
407:デフォルトの名無しさん
09/07/28 07:41:54
何事もバランスが大事
408:デフォルトの名無しさん
09/07/28 08:16:52
>>401
これ新宿駅の紀ノ国屋のところのウッドデッキかな?
409:デフォルトの名無しさん
09/07/28 09:26:57
rubygemsのライブラリをpull requestするときは、せめて
git pull git://pull先の人のmaster target_branch
git checkout target_branch
git rebaseまたはmerge my_branch
testrb1.8 test/
testrb1.9 test/
rake
rake1.9
gem1.8 build
gem1.9 build
の最後の7つを通してからにして欲しい
稀～に、pull先の人の公開masterの時点でrake全然通んねとか腐った状況もあるが
410:デフォルトの名無しさん
09/07/28 10:10:21
>>408
秋葉原のUDX1Fのテラス(タリーズ)じゃないの？
411:デフォルトの名無しさん
09/07/28 11:28:55
>>408
Matzの左上に高架線の架線柱が見えるけど、
新宿のウッドデッキは、そこより高い位置に線路はない。
412:デフォルトの名無しさん
09/07/28 13:24:17
なるほど。たしかにささだ氏のホームグラウンド的にもそっちだね。
413:デフォルトの名無しさん
09/07/28 13:29:53
>>409
なんかめんどくさッ！
414:デフォルトの名無しさん
09/07/28 13:41:41
だからgithub持ってくのには消極的反対なんだよ
415:デフォルトの名無しさん
09/07/28 13:48:18
何を言う、コード追加・変更の説得力のベースになるものが
一連の手続きとして試行可能だなんて鼻血が出るほど素晴らし過ぎるじゃないか
これが問題なく終わってれば後は口頭で説得するだけだろ？
最悪取り込まれなくても、「動作可能・動作検証可能」なコードとして存在できる
メーリングリストのどっかにちょろっと書かれたのを個々人が実行、なんてのよりはるかにマシ
めんどくさいというそれそのものには大きく同意はする
でも、githubで公開する時にだけやればいいだけだしさー
pushの前に一連の検証すればとりあえずオッケー、というのだけで安心感違うだろ
416:デフォルトの名無しさん
09/07/28 13:57:01
>>397
> なんか今だと関連MLの記事を数年分把握してて、
十回くらい上がるたびに同じような理由で却下されたような提案を、また得意
顔して出してくるやつがいたら、誰だってうんざりするだろ。
> 主要コミッタとのリアルつきあいも欠かさず行って、
不要。tsなんて誰も顔も知らなかった。
> 一日の何時間かをRubyに捧げる宣言しないとならなくて、
宣言なんて無意味。自分が必要だと思ったことをすればいいだけ。
> 事情があっても辞めるに辞められないようなイメージがあるわw
正直いってライブラリとか新規プラットフォームとかは、追加したはいいけど
後は知らんぷりで全然メンテしてくれなくなっちゃって困りまくり、という例
も多々あるので、継続できないのなら無理に入れてほしくない。
417:デフォルトの名無しさん
09/07/28 14:13:25
ライブラリや新規プラットフォームは、
メンテナと「サブメンテナ」を用意しないと対応しない、でもいいと思う。
もちろん「サブメンテナ」も活動しなくなる可能性はあるけど
少しだけフェイルセーフ。
418:デフォルトの名無しさん
09/07/28 14:14:49
メンテナを抜ける場合は別のメンテナ1人かサブメンテナ3人を紹介しないと抜けられないというのはどうだろう
419:デフォルトの名無しさん
09/07/28 14:18:02
ああっ、教祖や経典を崇める感じでシューキョーっぽかったRubyがとうとうマルチに手を
420:デフォルトの名無しさん
09/07/28 14:19:38
いいね。
あとブログや twitter なりでライブラリ保守されていないから改良した、
野良パッチをあてた、と書いている人を「スカウト」する積極さがあってもいいかも。
421:デフォルトの名無しさん
09/07/28 15:04:51
必要なのは優秀なコード書きじゃない
有象無象を束ねる優秀なマネージャー
まーつまりあれだ、いつも会社でウンザリしながらやってることを、
レベルも認識もバラバラの目の前にいない素人混じりの大人数に対して
金銭的報酬もないまま本来余暇であるはずの時間をつぎ込んで捌くような人が必要だということだ
422:デフォルトの名無しさん
09/07/28 15:12:12
>> 事情があっても辞めるに辞められないようなイメージがあるわw
>正直いってライブラリとか新規プラットフォームとかは、追加したはいいけど
>後は知らんぷりで全然メンテしてくれなくなっちゃって困りまくり、という例
>も多々あるので、継続できないのなら無理に入れてほしくない。
Rubyの内部事情ってそんなに酷いん？
423:デフォルトの名無しさん
09/07/28 15:18:34
ここ数年の Ruby の(リリース)マネージャは個人的には疑問だなぁ。
もっとアジャイルなほうがいいと感じてる。
優秀なコーダなんだから、
マネージャはモチベーションを上げたりするような
ファシリテータやコーチ的なのが合う気がする。
なんだか古臭いマネージングな気がして。
424:デフォルトの名無しさん
09/07/28 15:19:40
真の人柱だな…
425:デフォルトの名無しさん
09/07/28 15:34:36
>>422
Rubyの開発しやすさ、Rubyの中ではなんでもできる、作ってて超楽しい、というのが
物理的に広い開発では極めて悪い方向に作用している
これまで破綻しなかったのはそれこそ教祖様の数多の一声（の、却下）があってこそ
426:デフォルトの名無しさん
09/07/28 15:38:45
誰もやりたがらないことは
やらずに放っとけばいいよ
そのうち誰かがやってくれるから
これが Ruby クオリティ
427:デフォルトの名無しさん
09/07/28 16:43:24
tsって誰
428:デフォルトの名無しさん
09/07/28 16:54:40
>>425
Ruby標準・添付ライブラリが比較的マトモで、Railsがおおむねカオスなのはまつゆきの存在が大きい
Rubyからまつゆきを取り除くと、たぶんRailsになる
429:デフォルトの名無しさん
09/07/28 18:27:01
コントロールブレイク ネタにマジレスしているakrたんに萌えた。
430:デフォルトの名無しさん
09/07/28 18:33:34
> あとブログや twitter なりでライブラリ保守されていないから改良した、
> 野良パッチをあてた、と書いている人を「スカウト」する積極さがあってもいいかも。
blogやtwitterに書きっぱなし、野良パッチ当てっぱなしの人をスカウトすると、
結果がどうなるかは、まぁ、目に見えてますよね、そういうのはいやなんだ。
一方で、ruby-devにパッチ投げまくってくる人とか、IRCでパッチ書いてる人とかは、
誘ったりしてるよ。
> ここ数年の Ruby の(リリース)マネージャは個人的には疑問だなぁ。
それ以前の惨状をご存じの上で仰っておられるのでしょうか・・・。
まぁ、外から見ていると印象は違うかもしれない。
というか、coreの人間はtrunkしか見てないんで、リリース直前でもない限り、
リリースマネージメントはあんまり関係ないよ。
むしろそんな調子なのでちゃんとリリースマネージメントをやってくれる人がいないと、
いつまでたってもリリースできないんだ。
>>425
> Rubyの開発しやすさ、Rubyの中ではなんでもできる、作ってて超楽しい、というのが
> 物理的に広い開発では極めて悪い方向に作用している
Rubyと言っても、>>416のライブラリってのは標準添付な拡張ライブラリだろうから、
ソースは基本的にCだよ、Ruby使えるから素より遙かに楽だけど。
まぁ、そういういくつかのライブラリでの話であって、
全体的にそこまでの惨事になっているわけではないのでご安心ください。
>>428
あと、akrさんの存在もかなり大きいと思う。
431:デフォルトの名無しさん
09/07/28 18:51:43
そもそも、今までのコミッタってどうやってコミッタになってるの？
誰かに推薦されたとかそんな感じ？
どういう形でコミッタになったのか、ということと、コミッタになった後
どんな活動を続けているかand/or続けなくなってるか、ということって、
それなりに相関があるんじゃないかと思うんだけど、どうかな？
432:デフォルトの名無しさん
09/07/28 18:55:43
「惨状」とは思わなかったなぁ。
今は締切までに機能追加が間に合わないと、
次のリリースまで待たないといけなくてイマイチ。
期日の厳守のしすぎは目的と手段を見失っている感じ。
あと「惨状」とか「優秀なマネージャ」とか主観が強すぎ。
433:デフォルトの名無しさん
09/07/28 19:48:55
>>430
だからまあ、パッチの都合がよければpull requestを受け入れて、悪ければスルー。以上終了、って感じの
ゆるくて敷居の低いアプローチが求められてるんじゃね。
散々既出のネタに対して過去ログ嫁だのFAQ嫁だのレスしたりFAQ整備したりする必要はなくなるから。
どうせ何かの案が採用される率なんて手法に依らず千三つみたいなもんなんだから
却下がノーコストで提案の母数が増えるならそっちの方がよかろうと。
434:デフォルトの名無しさん
09/07/28 20:08:43
BTS使っているから、何度も寄せられる要望を抽出して、そこを見ろ、でもいいと思うし。
435:デフォルトの名無しさん
09/07/28 23:48:36
おお、Yuguiさん乙だ
自身のブログでgemの多言語化について詳細に書いてる。アクセス集まってるのか心なしか重い。
そういやRubyKaigiまだ見てないな・・・。
436:デフォルトの名無しさん
09/07/28 23:49:41
1.9系の話ね。
437:デフォルトの名無しさん
09/07/29 00:02:05
って一週間前に書いてるじゃん
なんで気づいてなかったんだ俺
438:デフォルトの名無しさん
09/07/29 00:12:05
漏れはとりあえずマニュアル整備してくれてる方々に最大の賛辞を送りたい
439:デフォルトの名無しさん
09/07/29 08:58:31
>>431
ざっとIRCでアンケートを取ったところ(IRCにいるということは現在アクティブであると推察される)、
パッチを投げてたら釣られた人と、立候補が半々くらいだった。
あとは、coreをいじる人とライブラリメンテナでは違いがあって、
ライブラリの場合はある程度完成しちゃうとそれ以降いじらなくなる人がいるかな。
最近ライブラリの追加に否定的な人が多いのはこの辺の事情も影響してる。
440:デフォルトの名無しさん
09/07/29 09:10:28
はッはッはッ、安定したライブラリに手を入れる必要なんてどこにあるんですカ
441:デフォルトの名無しさん
09/07/29 09:13:23
>>423
そうやってexperimentalな機能をとりこみ続けるとカオスになる。
今まで以上にいつまでも安定しない処理系を使ってもらえるか疑問。
ただし、とにかく色々出してみて有用なのを取り込んで安定させるというスタイルに向けて舵を切るべく、その意味でもgit化は期待できる。早くやれ。
個別の機能については「これは重要だから仕様凍結を破れ」と意見すれば受理される余地はある。
だから、メーリングリストで取り入れるべきだと主張すればいい。メーリングリストの敷居が高ければtwitterだっていい。
442:デフォルトの名無しさん
09/07/29 10:09:19
> blogやtwitterに書きっぱなし、野良パッチ当てっぱなしの人をスカウトすると、
> 結果がどうなるかは、まぁ、目に見えてますよね、そういうのはいやなんだ。
443:デフォルトの名無しさん
09/07/29 10:27:17
Rubyにしろなんにしろ属人的なものは減らしていかないと逝けないの鴨知れない
Matzだっていつまでも生きていられる訳じゃないんだし
444:デフォルトの名無しさん
09/07/29 10:33:55
個人の才能による作品を認めない優秀なマネージャ
445:デフォルトの名無しさん
09/07/29 10:35:32
芸術作品を日常使うと不便というのはよくある話
コルビジェの作った建築も雨漏りがしたっていうし
446:デフォルトの名無しさん
09/07/29 10:38:18
>>444
信念を持ってリジェクトできることこそが、マネージャーとして優秀である証
それがすばらしい作品であることと、それを取り込んだものがすばらしくなるかどうかは別
447:デフォルトの名無しさん
09/07/29 10:40:14
コンテストじゃないんだから勘弁してくれ
448:デフォルトの名無しさん
09/07/29 11:02:37
人間としても成熟してこそ優秀なマネージャ
449:デフォルトの名無しさん
09/07/29 11:59:51
>>439
すると、後は非アクティブな人のうち、パッチを投げて釣られた人・立候補した人の比率がどうかを見るといいんでしょうか？
ところでIRCでアンケート取ったとかいうことは、あなたは中の人ですか？
450:デフォルトの名無しさん
09/07/29 12:23:49
そういえば、一応すでにgithubにリポジトリのミラーはあるよ
URLﾘﾝｸ(github.com)
pushとかpull requestとかはできないけど
>>449
非アクティブな人にはアンケートという技が使えないので、MLあさらないといけないんですよね。
「SSH鍵」とかのキーワードで探せばいいと思うんだけど。
URLﾘﾝｸ(jp.rubyist.net) ちなみにIRCってのはこれ
451:デフォルトの名無しさん
09/07/29 12:24:15
アンケートを取ったのが中の人かどうかが何にどう関係するのかがわからない
452:デフォルトの名無しさん
09/07/29 12:29:51
>>440
> はッはッはッ、安定したライブラリに手を入れる必要なんてどこにあるんですカ
典型的なのはバグ報告が来た場合、セキュリティ絡みだととっても困る。
あとは本体の仕様変更に追従すべき場合、たとえばM17Nですね。
453:デフォルトの名無しさん
09/07/29 12:35:28
それくらいならそのコード読めばだいたい修正個所はわかるんじゃね
作成した人しかコードが触れないという呪いでもかかってるわけじゃなかろう
そのライブラリと分野のプロフェショノー（滑らかな発音）を一人は置く状態にしておく、というのもわかるが
でもそれだと修正要求に応じられるだけのバックグラウンド知識がライブラリメンテナに要求されるな
454:デフォルトの名無しさん
09/07/29 12:40:28
まーそりゃ本体組み込みや添付のライブラリは基本的なライブラリが多い（ことが期待される）から、
ライブラリのメンテナーの知識レベルは高いほうがいいと思う
ネットアクセスライブラリ作ったけど HTTP の知識よくわかんないどうすればいいかな、ではやっぱ困る
せめて、それなりに自分ひとりで意見組み立てた上で他の人のアドバイス募る、くらいでないと
455:デフォルトの名無しさん
09/07/29 12:43:20
>>453
URLﾘﾝｸ(www.ruby-lang.org)
こういうのが来て、メンテナと連絡がつかなかったらどうする？
456:デフォルトの名無しさん
09/07/29 12:52:50
些細な変更でも、誰がそれをやるかって言うのはあるな。
457:デフォルトの名無しさん
09/07/29 12:56:19
>>455
いやだから、rexml のソースは読めるだろ
初心者には無理だが、中級者かそれ以上なら首っ引きでなんとでもなるだろ
普段のだらだらした新機能要求ならまだしも、セキュリティバグなら「誰かできる人」がやるべきだろ
たとえば、「メンテナが学会出張中なのでそれが終わってからゼロデイ脆弱性のパッチをリリースします」でいいのか？
458:デフォルトの名無しさん
09/07/29 13:19:27
いいんじゃねえの
メンテナーの責任ってそういうことだろ
459:デフォルトの名無しさん
09/07/29 13:22:01
てか、そもそも、作成者が対応する義理も義務も何もないんだぜ
使って不都合なら、使用者側でなんとかするか、問題のないものに切り替えるべき
460:デフォルトの名無しさん
09/07/29 13:26:41
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
から始まるスレッドにも情報があるんだが、
このREXMLのDOS脆弱性は以下のような悪条件が揃っていた事例であった。
1. セキュリティ絡みのバグ
2. メンテナと連絡がつかない
3. 根本的な解決にはAPIの変更が必要
このため、当初はモンキーパッチを公開し、議論の上で根本的な解決を入れることになった。
議論はruby-dev, ruby-core, 非公開のセキュリティMLで行われた。
議論の結果、REXML::Document.entity_expansion_limitという新APIが追加された。
先述の通りメンテナ不在であったため、これらは前田さんによって行われた。
461:デフォルトの名無しさん
09/07/29 13:28:58
なぜ対応するかというと、はっきり言えば矜持なんだろう
「この状況はマズい」と感じて、「なんとかしないといけないものだ」と考えるから
じゃあ、みんなでよってたかってやればいいんじゃねーの、と思う
緊急用待機のメンテナーなんてなくてもいい
ライブラリ新機能更新用のメンテナーと、みんなが読み解けるように維持されたコード、この2つでたぶん充分だ
462:デフォルトの名無しさん
09/07/29 13:49:33
>>461
> じゃあ、みんなでよってたかってやればいいんじゃねーの、と思う
だめな例としてセキュリティインシデントが挙げられたんだと思うけど
> ライブラリ新機能更新用のメンテナーと、
> みんなが読み解けるように維持されたコード、この2つでたぶん充分だ
パッチ取り込みのコストを過小評価してないかなぁ。
というか、とりあえず誰か先に出てたgithubのミラーをベースに、
Redmineに上がっているバグを修正し、githubにupして、メールベースでpull希望だしてみたら。
463:デフォルトの名無しさん
09/07/29 13:54:42
仕事でRuby使っても大丈夫かどうか不安になってきました
464:デフォルトの名無しさん
09/07/29 14:01:41
誰かメンテナがいたとして、その人が修正コードを出してきたとしても、
「よっしゃ○○さん仕事早ええじゃあ早速コミットします」
じゃないだろやっぱ
それなりに複数の人が検証時間取ったり実はそれほどとってなかったりするだろ
じゃあやっぱ他の人が適当に修正コードらしきもの作ってもそれなりに検証されたりするんじゃね
メンテナのコードなら間違わない可能性が高いというのなら、そもそもバグは起こってないはずでさ
465:デフォルトの名無しさん
09/07/29 14:07:15
>>464
ヒント: メンテナにはコミット権がある
466:デフォルトの名無しさん
09/07/29 14:31:25
もともと、リリースがらみの仕事はまつもとさんに集中していた。
しかし、Rubyも1.8になるとライブラリの肥大化と安定性への期待が高まってきた。
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.2 リリース前
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.3
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.3^preview1予告
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.3-preview1
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.3でやっちまった例(logger)
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.4
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.4
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.5
特にリリースエンジニアリングが重要な課題だと認識されたのは、
1.8.3において、リリース直前のloggerに対する変更が原因で、
リリース版の1.8.3でRailsが動作しなかったことではなかろうか。
これにより、リリース直前の機能変更の危険性が開発陣で認知されることとなり、
仕様凍結の必要性が叫ばれることとなった。
その後、1.8.4や1.8.5において、凍結を実施してみたところ、
その感想はおおむね「多少マシになったけどまだダメ」といったところであった。
467:デフォルトの名無しさん
09/07/29 14:39:36
schedule for Ruby 1.8.6
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
1.8.6ではいくつかの大きな変更が行われた。
1つは武者さんのリリースマネージャの就任である。
これは、まつもとさんが1.9への変更に専念できると同時に、
まつもとさんやその他のcore開発者の1.8からの隔離を意味していた。
これにより、1.8系は格段に安定性を増すことが可能となった。
もう1つは卜部さんの安定版メンテナの就任とパッチリリースの導入である。
従来のRubyは、
1. 十分な機能追加があった場合
2. 大きなバグの修正があった場合
にリリースが行われていた。
しかし、これだと特定のバージョン+バグの修正という安定性を重視した
構成をとりづらいというデメリットがあった。
他にも、仕様凍結と併せてブランチを切ることで不要な変更の混入を抑止したり、
さらに長くした凍結期間といった、細かな変更も行われている。
これらの施策によりRuby 1.8.6は「最初のまともな安定版」となることができ、
1.8.6は高い評価を得ることとなった。
468:デフォルトの名無しさん
09/07/29 15:16:19
>>459
実際そういう考えが主流だった時代もあったけど、
今時それはよくないよね、って考えで
かつ実際血を流して対応してくれる人が出てきてくれた御陰で
Rubyは-pxxxのセキュリティパッチ適用リリースが出るように
なったわけで。
そうなるまでは機能追加とセキュリティパッチは
ごちゃ混ぜでリリースされてたわけで。
今考えるとすごい状況だよな
469:デフォルトの名無しさん
09/07/29 15:26:01
github は一度 push したブランチが訂正できないから嫌い
git に「ハッシュ値を変更せずにコミット内容だけ訂正する」みたいなオプションがあればいいのに
470:デフォルトの名無しさん
09/07/29 16:40:07
>>464
もうちょっと地に足をつけた上で提案としてまとめたほうがいいんじゃないかな
それぞれの場面で実際に誰が動くのか、動かなかった場合どうするのか考えないと、
話は進まないよ。
たとえばマスターはsvnのままという前提で行くと、pull requestされたパッチを、
どうやってgitの世界からsvnの世界へと持っていくか、とか。
471:デフォルトの名無しさん
09/07/29 18:14:35
>>469
お前さん、「ハッシュ値」って意味わかっていってる?
それが簡単にできたら、gitの前提が崩れさるだけじゃなく、
セキュリティ的に大騒動が起きるんだが。
472:デフォルトの名無しさん
09/07/29 22:56:33
>>451
答えてくれて嬉しいんだけど、この親切で素敵な人はいったいどこの誰だろう、という私の好奇心が満たされる。
473:デフォルトの名無しさん
09/07/29 23:04:36
>>457
そうだな、中級者かそれ以上なら誰でも直せるかもしれないな。
だから、誰だかわからんけど「誰かできる人」が直してくれるはずだから、
それまで放っておけばいいよな。
と、いうことになったら永久に誰も直さないかもしれないから、最終的には
責任を負うべき「メンテナー」というものが存在してるわけだろ？
474:デフォルトの名無しさん
09/07/30 02:21:46
>>473
まさにそういうことです。
で、メンテナ不在のライブラリは結構すでに多くて、
URLﾘﾝｸ(redmine.ruby-lang.org)
のうち、noneに加えて、まつもとさんと中田さんがメンテナになってるのは、
事実上メンテナがいないのものです。
また、メンテナがアクティブでないものは、why、serのと青木さんのかな。
前田さんのもほとんどメンテナンスされてないかも。
475:デフォルトの名無しさん
09/07/30 02:57:17
層の薄さが
476:デフォルトの名無しさん
09/07/30 04:52:54
>>473
わかってないんだな
どうして緊急性のあるものと緊急性のないものをわざと混同して話すんだ？
477:デフォルトの名無しさん
09/07/30 05:01:59
>>476
Redmineを見れば緊急性のないものがいくつか放置されているのが見て取れると思うんだけど
478:デフォルトの名無しさん
09/07/30 10:43:33
>>476
だから、
緊急性があるかどうかを判断して、
影響範囲を検討して、
修正を行って、
というのを誰がやることになるのかが問題だ、つってんだろ。
479:デフォルトの名無しさん
09/07/30 11:02:25
「緊急度が低い用件」という、何がしかの判断が済んでいるシロモノがあるように見えるのが間違いだな
判断されてるならそれに任せればいいという話にしかならん
「緊急なのか危険なのか誰にも全く判断されずに転がってる要件がいくつもあります」でなければならない
480:デフォルトの名無しさん
09/07/30 11:02:53
メンテナがいなかったり動いていない場合はとりあえず中田さんに振る、
というのが現状なんだが、遅かれ早かれ限界は来る
481:デフォルトの名無しさん
09/07/30 11:06:34
>>479
バグ報告の時点で重要度とか優先度とかあるのおかしいと思うんだ、俺
482:デフォルトの名無しさん
09/07/30 11:08:11
Rubyの赤は中田さんの血の赤というわけか
483:デフォルトの名無しさん
09/07/30 11:21:03
>>481
理想と現実の区別はしような
484:デフォルトの名無しさん
09/07/30 13:21:53
>>481
別に報告者の考えるそれがあるのはおかしくないじゃん
それらは必要なら受付者が変更するものなわけだし
485:デフォルトの名無しさん
09/07/30 14:14:32
本当は、報告されてきたバグや要望を、重要度や優先度をつけつつ担当者に割り振る、
Redmineマネージャみたいな人が必要なんだよね。
486:デフォルトの名無しさん
09/07/30 15:12:37
おまえらその議論の情熱を１０％でもコードにぶつければだな
487:デフォルトの名無しさん
09/07/30 15:21:06
そりゃただの逃避だ
我々に必要なのは神業コードでも大量データでもない
488:デフォルトの名無しさん
09/07/30 15:24:28
そーだな
「オレたちにできるのは愚直にコードを書き続けることだけだ！」
でできたのが山のような未管理のコードとライブラリ
現実見ようぜ現実
489:デフォルトの名無しさん
09/07/30 15:27:27
まぁ、この一連の議論で一人くらいは釣れないかなぁと思っているわけです。
* 新しく登録されるバグを誰かに押し付けるだけのお仕事
(誰に押し付けるかで半年ROMる必要があるか)
* 登録されたバグの中から簡単そうなのを見つけてパッチを作るだけのお仕事
(最初はお作法にあってないとかで、せっかく書いたパッチを書き直されるかもしれないけどめげない)
* 英語のわけのわからん機能追加に対して「何寝言言ってるんだバカ」と英語で答えるだけのお仕事
とかが君を待ってるぜ
490:デフォルトの名無しさん
09/07/30 15:31:54
抜けるときに10人生け贄、もとい後継者を紹介するみたいな闇ルールがなければ......
実は>>489も後継者探しなのではと疑ってしまう猜疑心の強い俺
491:デフォルトの名無しさん
09/07/30 15:39:34
特にどこかメンテナンスする義務を負わないように逃げまくって、
気の向いたときに気の向いたところを直すとかにすれば大丈夫だよ。
492:デフォルトの名無しさん
09/07/30 15:53:30
>>420
> あとブログや twitter なりでライブラリ保守されていないから改良した、
> 野良パッチをあてた、と書いている人を「スカウト」する積極さがあってもいいかも。
それやると、みんな沈黙するという結果に至る。
493:デフォルトの名無しさん
09/07/30 16:27:23
メンテナーがメンテナンスで食っていけないかぎり、この問題は解決しないのでは？
494:デフォルトの名無しさん
09/07/30 16:29:19
なんらかの報酬か褒賞か報奨はあってもいいかなとも思うが、そんなんないのが普通だよなとも思う
すぱっしょさんくすに本名載せたるから名刺代わりに使え、というのが限界かと(w
495:デフォルトの名無しさん
09/07/30 16:45:11
Ruby会議を利益が出るようにして、メンテナーに配分とか。
496:デフォルトの名無しさん
09/07/30 16:46:31
税金でメンテナーの給料を出す様に民主党のマニフェストに入れて貰うとか。
497:デフォルトの名無しさん
09/07/30 17:13:53
>>492
> blogやtwitterに書きっぱなし、野良パッチ当てっぱなしの人をスカウトすると、
> 結果がどうなるかは、まぁ、目に見えてますよね、そういうのはいやなんだ。
の発言のほうが沈黙するだろｗ
こんなの書いててすみません、みたいな。
498:デフォルトの名無しさん
09/07/30 17:38:44
やっぱり金だよな
499:デフォルトの名無しさん
09/07/30 18:03:34
Rubyビジネスなんとかで金出して優秀なマネージャをフルタイムで雇えばいいじゃん。
500:デフォルトの名無しさん
09/07/30 18:22:14
他のオープンソースプロジェクトって、どうやって回してるんだろう
501:デフォルトの名無しさん
09/07/30 18:33:17
>>494
> なんらかの報酬か褒賞か報奨はあってもいいかなとも思うが、そんなんないのが普通だよなとも思う
報酬をもらわないうちは、これの価値は無限大と思っていられる。
報酬なんか出したら、みんな手を出さなくなってしまう。
502:デフォルトの名無しさん
09/07/30 18:35:39
>>494
> すぱっしょさんくすに本名載せたるから名刺代わりに使え、というのが限界かと(w
ぼくの知覚圏内では、パッチ送って「ぼくの名前出さないで」な人は結構多いん
だが、Ruby宇宙ではそんなことないのか?
503:デフォルトの名無しさん
09/07/30 18:40:07
見返りが欲しい人は名前載せてもいいよそれくらいしかできないよ、という話かと
名前別にいらない、という人は少なくないな
504:デフォルトの名無しさん
09/07/30 18:58:59
>>501
誰もメンテナンスしていないライブラリ群をメンテナンスするには、フルタイムのメンテナーがいないと厳しい。
505:デフォルトの名無しさん
09/07/30 19:00:14
そんなことよりまあ聞いてくれよ、github で公開されてるライブラリをてきとうにフォークして、
それなりに分類になってるブランチを3つくらいいろいろコミットして push したら、
「Network」のとこの自分のアカウントのところがめっちゃ太く長く横に伸びてて凄く恥ずかしいんだが
うん、いや、それだけ
よく考えたらフォークした結果を push して公開する意味ってあまりないよね
自分でだけ使ってりゃ充分だもんな
506:デフォルトの名無しさん
09/07/30 19:08:02
>>504
Rubyでニート脱出のフルタイム在宅ワークがあります
（中級程度のCとRubyの知識があり各種ネットプロトコルとソケットを低レベルで理解しLinuxプログラミングとライブラリ作成の経験があって大規模ソース管理への造詣もある場合は業務未経験でも大歓迎！）
と煽るのはどうだろう
507:デフォルトの名無しさん
09/07/30 19:28:23
>>504
>>501はトンチンカンだった。ありゃ開発者のことだな。
メンテナはどっかのオプソ系会社の社員が仕事でやってても
おかしくはないな。
508:デフォルトの名無しさん
09/07/30 19:31:39
>>506
Rubyの求人ってそんなんばっかだよな
注釈や他の要件が長くて、しかもそっちが必須
だったら最初からRubyって書かないほうがスキルの高い人集まるだろうに
509:デフォルトの名無しさん
09/07/30 19:38:03
TTYとRUBYって似てるよね
510:デフォルトの名無しさん
09/07/30 20:38:34
>>508
「Ruby」って書くと、「注釈や他の要件に書かれた事柄を一人でできる人」って意味になる
511:デフォルトの名無しさん
09/07/30 20:41:02
Ruby1.9.1 のこないだ出たやつを Ubuntu にインストールしようと思ったんだけど、
なんか configure に必要なオプションってある？
だいぶ前に p0 のをインストールしたときは readline とか openssl とか指定しないといけなかった気がしたんだけど、
まだ自動で探さない？
512:デフォルトの名無しさん
09/07/30 21:49:30
Firefoxは、右上の検索バーで収益を上げているみたいだけど、Rubyも
何かできないかな？
MLに広告を載せるとか、www.ruby-lang.org/に広告のせるとか。
ユーザの負担にならない程度に、収益を上げる方法を考えるべきでは？
あまり広告主の影響受けるのも良くないけど。
現状は収益源って何かあるの？
513:デフォルトの名無しさん
09/07/30 21:58:40
>>512
誰の?
514:デフォルトの名無しさん
09/07/30 22:08:01
カッコイイ人が多いイメージのある県ランキング
URLﾘﾝｸ(ranking.goo.ne.jp)
515:デフォルトの名無しさん
09/07/30 22:11:37
>>492
それはやっぱり抜けるときのルールが不明確だからじゃね?
「どうやったら足抜け出来るかわからない」世界に飛び込むのって命がけじゃん。
特に期待されてるような「責任感の強い人」ほど責任が全うできるかわからなくて
二の足を踏むのでは?
例えば任期を一年単位にしてみるとかさー。
516:512
09/07/30 22:29:05
誰の収益源かというと、何と言っていいのか分からないけど、Rubyのメンテ
ナンスをしている人達、そのチームとしての収益なんだけど。
現状は収益0円？ だとすると、PCの電気代がかかるんで、むしろ
個人でお金を払ってメンテナンスしているんですかね。
517:512
09/07/30 22:36:58
メンテナ募金というか、寄付を募集するのも、まずいんですかね。
アメリカは、寄付の文化がありそうなので、Rubyなら集まりそうな
気もするけど。
フルタイムで働く賃金が出せなくても、足しになればいいのでは。
518:デフォルトの名無しさん
09/07/30 22:41:09
yes
519:デフォルトの名無しさん
09/07/30 22:49:54
BSD系とかだと寄付を受け付けてるし
OpenBSDはネットで入手できるものと中身は同じと断った上で
リリースのパッケージ売ったり、Ｔシャツ売ったりしてるな。
あっちはフルタイムの開発者もいるしセキュリティオフィサーもいるなあ。
フルタイムって意味ではぶっちゃけJRuby界隈に頼んだら受けてくれそうな気もするけど、
企業リソースに致命的なパートを依存すると完全にキンタマ握られかねなくて
頼むに頼めないってのもあるか。
520:デフォルトの名無しさん
09/07/30 22:55:12
Runyってオスだったのか
521:デフォルトの名無しさん
09/07/30 22:55:14
なにより、「フォークは自由だがRuby自体は俺のもんだ」って教祖様が常々
おっしゃってるので、組織的な動きがしにくいってのもあるんじゃね？
522:デフォルトの名無しさん
09/07/30 22:56:52
向かうところ敵なしの勢いのCPAN界はどうなってるよの。
523:デフォルトの名無しさん
09/07/30 23:00:20
>>517
一応Ruby Associationってのがあるんだけど、個人宛だとお金の配分とか受け渡しとかが面倒なんだよね。
個人的にはコンパイルファームが欲しいんだけど、まぁそれの管理者も必要になってしまうので云々。
ちなみにWebサーバやリポジトリ用のマシンは今NaCl持ちかな。
いきなりメンテナだと感じもわからないだろうので、まずはIRCから始めてみると、
コミッタの生態もつかめてよろしいかと思います
524:デフォルトの名無しさん
09/07/30 23:02:27
>>517
開発の仕事で食ってるサラリーマンからすると、たまに中途半端な金なんか
渡されても嬉しくもなんともない。
金が関わらないから、遊びという名目で仕事の外で付き合っていられるんで
あって、プロに金渡すなら、労力に見合った額をきっちり出してもらわんと困る。
>>519
Engine Yardという会社が、しばらく前からruby 1.8.6の保守を担当しているよ。
フルタイムの従業員を一人そのために割り当てている。
525:517
09/07/30 23:14:16
なるほど。確かに、仕事で開発している人なら、金とは関わりない世界で
携わりたいのは理解できる。
人手が足りなくて負担になってるみたいなんで、書き込んでみたんだけど。
私が少し考えて解決策がでるぐらいなら、もともと問題になってないよなあ。
526:デフォルトの名無しさん
09/07/30 23:15:36
>>524
技術の安売りはしない。これはあくまで仲間内/趣味での話
......って整理をしてるケースは多いよね。
haunとかもそうだった気がする。
527:デフォルトの名無しさん
09/07/30 23:19:17
>>525
いやその前に、あんたが何を「問題」視してるのかがわからんと話にもならん
RubyはRubyでそれなりの発展を（まだ）続けているし、ここまで来たらたぶん
Matz（やひょっとしてささださん）一人になっても、本人らが飽きず・食えてる
限りはそれなりに続くだろう
528:525
09/07/30 23:29:37
問題っていうのは、489の書き込みのように、人手が足りないこと。
人手を確保するにはお金じゃないの？という議論があったんで。
私は、「金が関わらない世界で遊びでやりたい」という気持ちを理解して
いなかったんで、的外れなことを言って申し訳ない。
529:デフォルトの名無しさん
09/07/30 23:34:35
>>528
そこは統一見解ではないというかインナーサークルと外側とで見解が違ったりするんじゃない?
あと金にしても端金なのか契約の元普通に人を雇える額なのかでも違ってくると思う。
実際未踏のお金(国からの補助金)でYARVは開発されてたわけだし。
530:デフォルトの名無しさん
09/07/30 23:39:51
>>526
「技術の安売りはしない」なんていう高尚な話じゃないんだ。
フルタイムの本業を持ってるメンテナがいて、本業が忙しく
なってRubyに手を出す時間が取れなくなったとする。
この場合、そのメンテナ個人にちょっと金を渡しても、問題は
全く解決しない。
個人が金を貰っても本業の忙しさには何の影響もないんだから。
メンテナの時間を確保するためには、そのメンテナが本業の
代わりにRubyをいじれるだけの金を出す、つまりフルタイムで
雇用してやるか、または、メンテナの所属する会社に適切な
代金を払ってメンテナの時間を買うか、どちらかしかない。
531:デフォルトの名無しさん
09/07/30 23:40:46
基本、締め切り付きで何かのアウトプットを求めるなら、
善意へ期待じゃなくて何らかの代価を払うべきとは思うけどね。
それこそセキュリティパッチみたいに「気が向いたら」だとマズいようなケースもあるし
そこぐらいはフルタイムの担当を雇いつつ代価を求めてもいいと思うけどね。
まあ陳腐な例だけどそれこそＴシャツ売るでもいいわけだから。
532:デフォルトの名無しさん
09/07/30 23:43:20
問題はだ。フルタイムで誰ならおまいら納得するんだと。
おまいらが期待するような人材は、大概他でバリバリやってるんだってば。
今のところmatzがフルタイムぽいんだが不満なのか？
533:デフォルトの名無しさん
09/07/30 23:46:21
>>528
「金が関わらない世界で遊びでやりたい」と言ってる
わけではなくて、「遊び」という形で背負える程度の
責任しか背負いようがないだけ。
個人に小銭を渡しても、使える時間が増えるわけじゃ
ないんだから、背負える責任の大きさは変わらない。
だから、使える時間を増やせるほどの額じゃなければ
受け取るわけにはいかないのだ。
534:デフォルトの名無しさん
09/07/30 23:46:47
matzがフルタイムっぽいのは理解したうえで、さらに人手を増やすには
どうしたらいいか、という話じゃないの。
matzが健在ならオールオッケイなのか？
535:デフォルトの名無しさん
09/07/30 23:48:29
じゃあどこまで規模を広げるべきか、そういう話になるはずだよな。
なってるか？
金があるから大きくなるんじゃなくて、大きくするために金が必要
ってのが普通の流れだよ。
536:デフォルトの名無しさん
09/07/30 23:51:27
何かアプリ作れよ。世界中で使われればRubyに興味を持つやつが増える。
ビジネス的な価値を見いだすところが出れば金が集まる可能性も高まる。
537:デフォルトの名無しさん
09/07/30 23:52:50
どこまで人を貼り付けないとマズいのか、ってところだよな。
1.8.6にフルタイムで人が貼り付いてるのは多分Rails関連でしょ?
あとはサポート継続中のリリースに対してセキュリティ対処出来る分だけの
リソースがあるなら当面はいいんじゃないかなと思うけど。
538:デフォルトの名無しさん
09/07/30 23:54:51
matzは布教活動で忙しいんだよ。
539:デフォルトの名無しさん
09/07/31 00:09:56
>>536
Tracの前にRedmineが作られていれば、キラーアプリになれたかもね。
MovableTypeと同等のRuby製品があって、ちょっとだけ早く出ていれば、
Rubyの方がレンタルサーバで優遇されたかもね。
PHP5と同時期にmod_rubyというか、mod_railsがあれば、そっちにも
人は流れたかもね。インストールの手間は大して変わらんし。
結局、Rubyは何かを作ってきた、世の中を動かして来たって実績がほとんど無いんだ。
常にアンチテーゼを提出してみるだけの文化が染みついてるんだ。
万年野党もいいじゃないか
（って感じで関わる人間が多い気もするんだ実際）
540:デフォルトの名無しさん
09/07/31 00:13:33
>>532
matzはコミット権の剥奪を申し渡されるようなタイプだから、
仕様策定者、開発者としてはともかく、保守担当者としては
完全に役者不足。
541:デフォルトの名無しさん
09/07/31 00:20:20
向き不向きってのはあるからね
ある意味フルタイムで雇っているなら自分の思いと求められていることとが
相反したときでも契約をよりどころに割り切って行動できるかもしれないけど、
その辺ナシで自分の思いと反する行動をとるって負担度が高いよね。
542:デフォルトの名無しさん
09/07/31 00:27:46
>>527
実際のところ、開発に関しては放っておいても全然問題は
ないだろうね。
今まで同様、なんとなく続いていくだろう。
問題は、何度も出ているように、保守。
543:デフォルトの名無しさん
09/07/31 00:37:10
>>539
portupgradeとかtDiaryとか。
まぁ、Rubyは世界を変えるためのものじゃなくて自分の日常をちょっと便利にするためのものなんで、(Railsは知らんよ)
そういう意識の人は多いかもね。
544:デフォルトの名無しさん
09/07/31 00:38:32
>>539
Tracのお陰でpython人口が増えたとも思えない。敢えてrailsをキラーアプリと言わないのも意味不明。
今せっかくRubyの人気が世界中で高まってきているところで、ライブラリ1.9への対応という難題が上がってきていて、今までの様になんとなく誰かがやるのを待つっていうのは、評判を悪くすることになりはしないか？
野党でもいいというのは、他の言語もバリバリできるできる人の発想。凡人は、特化することによってしか活路はない。matzは凡人用のlispとしてRubyを作ったと言ったら、穿ちすぎ？
545:デフォルトの名無しさん
09/07/31 01:09:23
なるほど、こういう人たちがいるがために今の状況があるわけか
546:デフォルトの名無しさん
09/07/31 01:21:50
>>544
Railsは実際に依存している1.8.6がRails関連の金で保守されてるからでしょ。
悪く言えばそこでもう切り離されちゃってる。
547:デフォルトの名無しさん
09/07/31 06:42:33
結局、保守担当者として1人フルタイマーが必要ということ？
Railsが1.9に依存するようになれば、企業が、保守担当者（保守のみ）の
人件費を負担してくれるようになるかな。
548:デフォルトの名無しさん
09/07/31 07:41:39
国がΣプロジェクトに費やしたお金を考えると、メンテナーの二人や三人を税金で賄ってもどうってことはない。
549:デフォルトの名無しさん
09/07/31 08:04:28
Rubyが未踏に選ばれたのは「国産だから」だよね
550:デフォルトの名無しさん
09/07/31 08:11:57
>>548
今まで浪費してきたんだから次の浪費も許されるべきだ、
なんて論法だと身代が潰れるぞ
せめてこうこうこういう理由で必要だから、って言い方にしないと
551:デフォルトの名無しさん
09/07/31 08:26:32
>>549
選ばれる以前の話で、未踏の応募資格は日本人または在日であること
552:デフォルトの名無しさん
09/07/31 08:28:39
>>551
？
553:デフォルトの名無しさん
09/07/31 08:59:38
>>550
済まん。余計な事を書いた。
あの無駄になった２００億以上のお金の何分の一でもあればな～とつい思ってしまった。
KAMEプロジェクトのように、国際貢献になるから、予算つけてくれないかなと思わざるを得ない。
554:デフォルトの名無しさん
09/07/31 09:08:11
そしてgoogleからの圧力によりスーパー301条の対象に。
555:デフォルトの名無しさん
09/07/31 10:10:54
やっぱりお金と人を投入すれば
速くなって使いやすくなって
JavaやPerlやPHPを駆逐していくんだらうか
556:デフォルトの名無しさん
09/07/31 10:18:45
原理的にそれほど速くはならんだろ
そりゃ歴代Rubyの中ではどんどん速くなるだろうが、JavaやPerlにはもともと敵わない
てきとーに作られた中規模Javaプログラムは、必死でチューニングした中規模Rubyスクリプトよりもたいてい速い
応答速度が速いほうがいいプログラムの需要はどうあっても尽きないから、駆逐は無理だ
Rubyスクリプトが高速に動作する環境を用意した場合、他の言語のプログラムは爆速で動く
というわけで、ハードウェア大国日本の面目躍如としてRuby専用CPUの開発をだな
557:デフォルトの名無しさん
09/07/31 10:21:51
YARVチップですか
558:デフォルトの名無しさん
09/07/31 10:33:10
>>556
そういう姑息な真似をしないとPerlより速くならないRubyはクズ
まで読んだ
559:556
09/07/31 10:34:34
>>557
YARVって何？
560:デフォルトの名無しさん
09/07/31 10:46:53
>>559
血税を投入してJRubyより劣った仕組み
561:デフォルトの名無しさん
09/07/31 10:53:02
スピードなんていらない。使いやすければそれでいい。
早いプログラムがほしけりゃFortranで書いてスパコンで実行させるからさ。
欲しいのはパパッと書けて１０秒ぐらいで忘れられるコードだよ。
ただ、rubygemsはno-rdoc no-riをつけないと遅くてたまらん。ああいうところは
改善しないのかな
562:デフォルトの名無しさん
09/07/31 11:02:23
rubygem 開発陣のマシンが超パワフルなので問題ありません
563:デフォルトの名無しさん
09/07/31 11:02:37
>>560=本物の>>556乙
564:デフォルトの名無しさん
09/07/31 11:06:05
>>562
バージョン 0.x 時代の YAML 展開ハングアップのことまだ根に持ってるのか(w
565:デフォルトの名無しさん
09/07/31 11:25:14
シェフのまかないつきRubyエンジニア求人来た！これで勝つる！
URLﾘﾝｸ(headlines.yahoo.co.jp)
566:デフォルトの名無しさん
09/07/31 11:36:05
>>564
Debianユーザにとっては笑えない…こないだのlennyリリースまでずーっとこの問題抱えざるを得なかったから
567:デフォルトの名無しさん
09/07/31 11:57:09
バイト列自体が文字エンコーディング ENC である ASCII_8BIT のでっかい文字列があって、
このでっかい文字列のエンコーディング情報はとりあえず変換したくないという場合、
特定の文字列の正規表現をマッチさせたい場合って
/#{"特定の文字列".toENC.force_encoding(::Encoding::ASCII_8BIT)}/ =~ ASCII_8BIT文字列
か
/#{"特定の文字列".toENC}/ =~ ASCII_8BIT文字列.dup.force_encoding(::Encoding::ENC)
のどっちかしかない？
568:デフォルトの名無しさん
09/07/31 12:10:09
>>567
後者しかない
569:デフォルトの名無しさん
09/07/31 12:18:50
前者もエンコーディングが合ってるからマッチはするはず
irb> /#{'わんわんお'.force_encoding(Encoding::ASCII_8BIT)}/ =~ 'わんわんわんお'.force_encoding(Encoding::ASCII_8BIT)
6
570:デフォルトの名無しさん
09/07/31 12:24:26
/#{'好'.encode("EUC-JP").force_encoding(Encoding::ASCII_8BIT)}/ =~
'テスト'.encode("EUC-JP").force_encoding(Encoding::ASCII_8BIT)
ダメな例
571:デフォルトの名無しさん
09/07/31 12:26:52
ていうか、実は両方ダメ
/#{'表'.encode("sjis").force_encoding(Encoding::ASCII_8BIT)}/ =~
'表'.encode("sjis").force_encoding(Encoding::ASCII_8BIT)
572:デフォルトの名無しさん
09/07/31 12:30:43
というわけで、正答例
src="テスト"; pat="好"; enc="euc-jp"
/#{Regexp.escape(pat.encode(enc).force_encoding(Encoding::ASCII_8BIT))}/ =~
pat.encode(enc).force_encoding(Encoding::ASCII_8BIT)
573:デフォルトの名無しさん
09/07/31 12:45:30
あ、うん、ここだけ前時代的問題が噴出するよね
# -*- coding: utf-8 -*-
require 'open-uri'
uri = "ｽﾚﾘﾝｸ(tech板:571番)n"
html = open(uri).read
p /#{"表".encode(Encoding::SJIS)}/ =~ html rescue puts $!
p /#{"表".encode(Encoding::SJIS).force_encoding(Encoding::ASCII_8BIT)}/ =~ html rescue puts $!
p /#{"表".encode(Encoding::SJIS)}/ =~ html.dup.force_encoding(Encoding::SJIS) rescue puts $!
動作しそうな記述のうちで実際にマッチするのは最後だけというのがなんとも
incompatible encoding regexp match (Shift_JIS regexp with ASCII-8BIT string)
too short escape sequence
1732
574:デフォルトの名無しさん
09/07/31 13:04:53
CSIだからJavaみたいにユニコードリテラル表現を用意しておいて
最悪ファイル上の非ASCII文字列はnative2asciiつかうって逃げ道も美しくないしなあ
575:デフォルトの名無しさん
09/07/31 13:07:06
外人さんって force_encoding と ASCII_8BIT 好きだよね
576:デフォルトの名無しさん
09/07/31 13:12:05
狂犬発動してUTF8をデフォルトエンコーディングにしておけばこんなことにはならなかったのに…
Windows憎しで避けてたらLinuxすら標準になっちゃったのにな。
577:デフォルトの名無しさん
09/07/31 13:13:39
WindowsではいまだシフトJISが通らないと困ることも多いだろ。
UTF-8で統一強行したらみんな不幸だわ。
578:デフォルトの名無しさん
09/07/31 13:19:44
>>576
Shift_JISのHTMLを読み込んだらUTF-8になってるってこと？
579:デフォルトの名無しさん
09/07/31 14:37:14
force_encoding ってバイト列のほうは変更しないから何度繰り返しても大丈夫だよね？
580:デフォルトの名無しさん
09/07/31 15:01:13
>>573
文字を文字として扱いたいときには、きちんとエンコーディングをつける。ただそれだけのこと。
バイナリとして操作したらはまるにきまってる。
>>576
そういう問題ではないと思うけど。
>>579
まぁ、そうだけど、なんで何度も繰り返したいの？
581:デフォルトの名無しさん
09/07/31 15:47:41
あ、1.9の話してる
クラス変数って継承されるの？ 継承されないの？
582:デフォルトの名無しさん
09/07/31 15:57:32
全パターンありそうだな
URLﾘﾝｸ(www.google.com)
583:デフォルトの名無しさん
09/07/31 16:37:00
>>580
>まぁ、そうだけど、なんで何度も繰り返したいの？
繰り返したいんじゃなくて一回しか呼ばれないことを保証できないんじゃない?
ライブラリ的なものを作ってると悩むかもしれん。
584:デフォルトの名無しさん
09/07/31 16:53:27
>>581
される、でFA。
継承というのもまた違う気がするが。共有というべきかな。
585:デフォルトの名無しさん
09/07/31 17:17:09
>>582
どうしてこうなった…
586:デフォルトの名無しさん
09/07/31 17:55:50
あれ、「1.9ではクラス変数は継承されない」という説明があるのはなんで？
587:デフォルトの名無しさん
09/07/31 19:56:26
>>561
無理だろう
仮に、rubygems開発チームが改善する気になってくれたとしても
現時点でrdoc＆ri生成がデフォルトになってる以上、もうどうにもならんと思う
そもそも最初から、rdocとriの自動生成なんてやるべきではなかった
発想がいくらなんでも富豪的すぎる
588:デフォルトの名無しさん
09/07/31 21:37:42
URLﾘﾝｸ(shyouhei.tumblr.com)
gitktkr
589:デフォルトの名無しさん
09/07/31 22:55:02
ｷｬｰｼｮｳｻｰﾝ
これは抱かれてもいいレベル
590:デフォルトの名無しさん
09/07/31 23:10:48
30時間はすげーな、mput超乙
しかもこれから来るpull requestを全部捌くわけ？
591:デフォルトの名無しさん
09/07/31 23:17:08
さて、git.ruby-lang.orgへの移行はどれくらい先になるか
592:デフォルトの名無しさん
09/07/31 23:38:01
卜部おにーさんは格好良いなあ
593:デフォルトの名無しさん
09/08/01 05:24:25
>>587
それこそrubygems開発陣のマシンでは「ちょっと待つだけ」だったんだろうな
594:デフォルトの名無しさん
09/08/01 06:13:33
>>577
それはない
595:デフォルトの名無しさん
09/08/01 07:24:26
1.9.1で動いてたライブラリやスクリプトが1.9.2で動作しなくなる可能性って今のところどのくらいある？
596:デフォルトの名無しさん
09/08/01 07:40:25
1.9.1で動作してるなら「めったに無いんじゃないかなー」という程度
まだ仕様が固まったわけじゃないからはっきりとはなんとも
「1.9.2を見据えるとやらないほうがいい書き方」というのは今んとこ無いはず
597:デフォルトの名無しさん
09/08/01 10:44:17
そろそろ RAA for 1.9 作って未対応のものを締め出すのがいいと思うんだ
598:デフォルトの名無しさん
09/08/01 10:44:59
1.9系はスルーして2.0から使うのが本道
599:デフォルトの名無しさん
09/08/01 11:36:18
>>598
書き込むスレ間違えてますよ
ｽﾚﾘﾝｸ(tech板)
600:デフォルトの名無しさん
09/08/01 14:34:15
そろそろ移動
loopとtimesが似てるとは思わない、そもそもloopにカウンタがほしいとも思ってない
でもあれば便利ってのは理解できる
Kernel#loopが存在している上で新たにIntegerにメソッドを加えれば
単に「繰り返す」ではなく「（ある値から）数え上げながら処理を繰り返す」という意味になる（できる）し
それがtimesの「ある値まで数え上げながら処理を繰り返す」と対称だということ
（timesのメソッド名から考えれば「指定回数繰り返す」なんだけど、ブロック引数取った場合には）
つまり数値が始点か終点となるかの違い
ただ始点のデフォルトが0なのに対して終点のデフォルトは極大だから終わりがない
でもInteger#loopという名前は初めから微妙だと感じてるし
そのせいで批判されまくってるんじゃないかと
0.start {|i| puts i }
やっぱり名付けのセンスないな・・・
601:デフォルトの名無しさん
09/08/01 18:55:13
まあ1.9にしたい香具師ががんばって人柱に成ってれば良い。
それまで今までの互換が有る1.8使ってるから。
信者増やして金儲けしたいなら、リナックスVISAクレジットカードみたいにルビークレジットカードでも作ると良いのかもな。提携カードビジネスは儲かりそうだ。
どんどん宗教法人の様層を呈して来て、松本教祖に金が集まる仕組みに成って来たな。
602:デフォルトの名無しさん
09/08/01 19:00:51
nokogiri-1.3.3のtest配下に2ch.htmlとかが増えてるんだが
何があったんだw
603:デフォルトの名無しさん
09/08/01 19:31:20
そりゃあろいんの「2チャンミテマスヨ」という無形のプレッシャーに決まってるじゃん
whatchanged を見る限り、非 UTF-8 HTML を Nokogiri::HTML(html).to_html して
doc.encoding がうまくいくかどうかテストするために入れたっぽい（若干改変してるが）
ある程度複雑な Shift_JIS の HTML が必要だったのだろう
604:デフォルトの名無しさん
09/08/01 19:34:42
あ、このへんね
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
605:デフォルトの名無しさん
09/08/01 19:44:27
ねー、自分では作（れ）る気しないけど、あったら便利だなというライブラリってなんかある？
606:デフォルトの名無しさん
09/08/01 20:15:43
>>605
blade
607:デフォルトの名無しさん
09/08/01 20:37:49
>>605
・Win32APIの使いやすいラッパー
・pure ruby版Nokogiri
・pure rubyかつ強力な画像処理ライブラリ
ライブラリじゃないけど番外で
・RDEのような軽量開発環境＋クロスプラットフォーム＋安定
・GUIビルダー
608:デフォルトの名無しさん
09/08/01 21:41:11
せいぜいサムネールが作れてあとは縦横のサイズが取れるくらいの
画像処理ライブラリは欲しいなー。
RMagickはかさばりすぐる。
609:デフォルトの名無しさん
09/08/01 22:24:17
pureRuby厨うぜえ
超遅い部分をCで書き直して何が悪いんだよ
610:デフォルトの名無しさん
09/08/01 22:36:24
pureRuby厨分類
* 原理主義 (とにかくPureRubyこそ至上、MRI以外で困るから)
* 標準添付はよい(rootのない環境で困るから)
611:デフォルトの名無しさん
09/08/01 22:41:56
>>609
過剰反応うぜえ
612:デフォルトの名無しさん
09/08/01 22:49:07
REXMLがPure Rubyであの重さなわけだが・・・
613:デフォルトの名無しさん
09/08/01 22:55:42
>>610
「CGIで動かないと困る派」も追加で
614:デフォルトの名無しさん
09/08/01 23:28:34
nokogiriは素晴らしい
615:デフォルトの名無しさん
09/08/01 23:29:28
自演乙
616:デフォルトの名無しさん
09/08/01 23:31:12
だーれーのー
だーれーのー自ー演ー
>>613
「CじゃなくPureRubyで作りましたライブラリ」の動作速度でCGIが動いたら果てしなく困ると思うんだけどね
インストールさえできれば運用はどうでもいいのかしら
617:デフォルトの名無しさん
09/08/01 23:35:54
オバマ
618:デフォルトの名無しさん
09/08/01 23:36:07
pure rubyでも拡張ライブラリでもいいじゃない、使い分ければ
619:デフォルトの名無しさん
09/08/01 23:44:31
拡張をCで書く理由の8割くらいは「CGIとかで動作させたとき遅くてやってられないから」だと思うんだが
620:デフォルトの名無しさん
09/08/01 23:46:37
>>616
用途によってはpure rubyの速度で十分だし
そもそもCGIでは、たいていの場合pure ruby以外に選択肢がない
俺の経験から言えば
複雑な画像処理やファイル圧縮は厳しいが、JSON/YAMLのパースや文字コード変換程度なら特に問題はないなー
HTML（XML）のパースあたりになってくると微妙
621:デフォルトの名無しさん
09/08/02 00:22:23
>>619
Cの拡張ライブラリを入れることができるような環境であれば、そもそもCGI使わなくね？
今ではmod_rubyとかFastCGIとか色々あるんだし
622:デフォルトの名無しさん
09/08/02 00:45:51
「今では」、mod_rubyはありえんだろ
623:デフォルトの名無しさん
09/08/02 02:34:54
CじゃなくてもJavaで書き換えても爆速になるんじゃね？
>>556さんどうなんよ？
624:デフォルトの名無しさん
09/08/02 05:34:44
>>621
そうだねCで拡張書けるだけのCの知識があればRubyなんて使う必要ないよね全部Cで書くよね
625:デフォルトの名無しさん
09/08/02 07:51:52
速度が必要なところはCで、それ以外はもっと高級な言語でってのは普通のことだろ
626:デフォルトの名無しさん
09/08/02 08:59:22
>>624-625がどこにどう反論してるのか理解できない
627:デフォルトの名無しさん
09/08/02 11:14:10
遅いメソッドをプロファイラで割り出して、拡張ライブラリとしてCで書き直すって
よくやるんだけど、思った程速くならないんだよなぁ。
やっぱ rb_funcall とかしまくるくらいなら意味ないのかな？
628:デフォルトの名無しさん
09/08/02 11:48:16
Purerubyが遅いというのは甘え。どうせクソ設計のせい。
（性能が）足りぬ足りぬは工夫が足りぬってな。
629:デフォルトの名無しさん
09/08/02 12:02:12
すごいな、全世界のRubyユーザーが揃ってクソ設計してるなんて
…それって言語側に原因があるんじゃね？
630:デフォルトの名無しさん
09/08/02 12:07:25
nokogiriとREXMLの圧倒的な差
631:デフォルトの名無しさん
09/08/02 12:07:45
>>628
さすがにC言語と比較してそれはない
632:デフォルトの名無しさん
09/08/02 12:14:16
>>605
win32用の高速なcrc16計算ライブラリが欲しい。今すぐに！
633:デフォルトの名無しさん
09/08/02 13:06:46
.NET FrameworkにCRC32すら入ってなくて絶望した俺が通り過ぎます
634:デフォルトの名無しさん
09/08/02 13:28:11
>>632
Cでいいか？
635:デフォルトの名無しさん
09/08/02 13:55:02
rubyも、pure ruby界とC界の境界面で高いコストが掛かる実装なの？
頻繁にCで書いたメソッド呼ぶとマーシャリングで余計遅くなるとか？
636:デフォルトの名無しさん
09/08/02 14:03:54
Windowsを使ってるやつにCRCなんぞ不要。ファイルが壊れてたら
再送すればいいだけ。
637:デフォルトの名無しさん
09/08/02 14:10:40
つかMD5やSHA-1じゃなくあえてCRCが要求される場面って何？
速度的にCRCが爆速ってわけでもないのに
638:デフォルトの名無しさん
09/08/02 14:11:17
>>637
既存のファイルフォーマットなりプロトコルがCRC32を使っている場合
639:デフォルトの名無しさん
09/08/02 14:18:11
歴史的経緯って奴だな
新規でCRC32を使用することはなかろう
640:デフォルトの名無しさん
09/08/02 16:09:29
CRC32だったらZlib.crc32が使えるね。
CRC16だと自分で用意しないとダメだなぁ。
641:デフォルトの名無しさん
09/08/02 18:30:01
>>262-263 あたりのnokogiriの話。
どうもnokogiriのWindows版gemに同梱されてるDLLは
libXML2の公式サイトからリンクされてる
URLﾘﾝｸ(www.zlatkovic.com)
のもののようなので、
URLﾘﾝｸ(www.zlatkovic.com)
のDLLの情報等を参考にしつつ、libiconvの1.13に
森山さんのところのパッチ
URLﾘﾝｸ(www2d.biglobe.ne.jp)
をあてたものを
MinGW/MSYSでビルドして、MSYS環境でそのままビルドすると
libiconv-2.dllとかしか出来ないので、ビルド時に生成された*.oに
libiconv-2.dllから抜き出したdefファイルを加えて
dllwrapでiconv.dllを生成……
ということで結果としてlibiconv-1.13-ja-1相当のiconv.dllを
作成してdllの検索パス(nokogiriの元の構成通りだとbin直下)に
配置したところ、>>262の
>#Shift_JISの範囲外の文字を含んだWindows-31J(=CP932)エンコーディングの文字列
>irb(main):001:0> s="<html><HEAD><TITLE>1１①1１①</TITLE></HEAD><body></body></html>"
>=> "<html><HEAD><TITLE>1１①1１①</TITLE></HEAD><body></body></html>"
>#Windows-31JエンコーディングでHTMLパース。失敗。
>irb(main):003:0> Nokogiri::HTML.parse(s,nil,'Windows-31J')
が通るように。
とりあえず今回生成したiconv.dllは
需要があるかどうか何とも言えないけどうpっておきます。
URLﾘﾝｸ(www1.axfc.net)
642:デフォルトの名無しさん
09/08/02 18:36:46
pureRubyじゃないときに困るのは一部のプラットフォームにしか対応してないとか
バイナリパッケージがない場合とかですかね。
もはやmswin32(というかActiveScriptRubyとOne-Click Installer)が
Rubyユーザの最大勢力なわけで、大抵そのあたりでもめるというか。
643:デフォルトの名無しさん
09/08/02 19:50:03
最大勢力の欲求が常に正しいとは限らないし、満たしてやる必要もない
644:デフォルトの名無しさん
09/08/02 20:00:54
と、思いつつ最終的に「満たすことになる」のが世の習いでもあり。
実際（別視点で見たときの）最大勢力であるRails勢の望みは
リリースエンジニアリング含めかなり呑むことになったわけで。
もちろん言語仕様的な部分とかでまつもとさんが一線を守るのは
悪くないけれども、じゃあこの点については実際のところどうなの、
という話になるわけで。
645:デフォルトの名無しさん
09/08/02 20:10:58
>>643
The Netが商用利用に解放された当時、そのころの細い回線を大事に
使っていた人たちのうちくちさがない人々は
「一般人にネットなど与えるな」などと言ったものでした
当時の旗振り役が答えて曰く
「そうなればいずれ彼らは自分たちでネットを生み出し今のネットにとって変わるだろう」
「もしそうであればそのとき君たちの居場所はあるだろうか?」
と
まあ実際その通りになったのですが
646:デフォルトの名無しさん
09/08/02 20:34:41
へー
自分たちでネットを生み出したんだ。そんな歴史初耳w
647:デフォルトの名無しさん
09/08/02 20:44:12
>>初心者スレの821
rb_block_tのproc見て、なかったらiseq->argc見れば変換はいらなくね？
とはいえそんなのはキモすぎて御免だが
648:デフォルトの名無しさん
09/08/02 21:33:52
>>646
無知ですねえ。
これだから自称古参は困るw
649:デフォルトの名無しさん
09/08/02 21:35:58
じいさんの昔話はレトロ板でやってくれ
650:デフォルトの名無しさん
09/08/02 23:55:32
>>632
>>640
URLﾘﾝｸ(www.zorc.breitbandkatze.de) ( URLﾘﾝｸ(www.zorc.breitbandkatze.de) )
URLﾘﾝｸ(boost.cppll.jp)
651:デフォルトの名無しさん
09/08/03 10:41:21
年寄りは今の時代についていけないからな。昔話するしか無い。
戦争は悲惨だから嫌だとか逝って競争することを放棄した年寄りが日本を駄目にした。気がつけば競争力無くて景気低迷。ちゃっかり競争が無いはずの非資本主義の支那に美味しい所を持っていかれてる。
ピュアルビーが遅いのって、ルビーインタラプタが遅いからだろ。
信者は、教祖の実装がゴミのせいで遅いと口が避けても言えないってだけじゃ。
652:デフォルトの名無しさん
09/08/03 10:45:38
URLﾘﾝｸ(jp.rubyist.net)
みれない
653:デフォルトの名無しさん
09/08/03 10:57:44
>>651
URLﾘﾝｸ(hideyoshi.2ch.net)
654:デフォルトの名無しさん
09/08/03 11:43:28
インタラプタについて語るスレになりまつた。
655:デフォルトの名無しさん
09/08/03 11:57:12
1.8のコードなんてもう読んでないからインタラプタとかよくわかんあい
656:デフォルトの名無しさん
09/08/03 12:25:25
>>651
さっさと核戦争やれ
まで読んだ
657:デフォルトの名無しさん
09/08/03 12:47:33
ルビーインドヒマラヤ
658:デフォルトの名無しさん
09/08/03 13:15:34
>>651
その種の文句は方々で言われてるだろ。
matzはコミット権を取り上げると脅される程度の扱いだぞ。
659:デフォルトの名無しさん
09/08/03 13:24:37
>>658
あんまりネタを引っ張ってると恥ずかしいよ
あれはあくまでテストとドキュメント書けって話だし
660:デフォルトの名無しさん
09/08/03 14:04:53
でもまあ「コードがドキュメントだ」的な発言は粉砕されてしまうようになったかな
661:デフォルトの名無しさん
09/08/03 14:11:11
実際にマニュアル文書こうとするとわかるが、Ruby スクリプト部分に関してはコード読ませたほうが早い
それこそ「変数 i に整数 10 を代入する」レベルのことにしかならなかったり
必要なのは、個々のメソッド動作の詳説ではなく、網羅的なメソッド動作一覧だったりする
662:デフォルトの名無しさん
09/08/03 15:16:33
スクリプトの説明とマニュアルは違う
コードの動作を知らせるのならそりゃコード読ませたほうが早いが
コードの動作が何を意図しているのかを明確にするために
ドキュメントを書くべき
663:デフォルトの名無しさん
09/08/03 15:18:15
ドキュメントとマニュアルは開発者が書かなくてもよい
別の人が書いてもよい
664:デフォルトの名無しさん
09/08/03 15:32:53
ドキュメントやマニュアルとはそもそもなんぞやという話に
665:デフォルトの名無しさん
09/08/03 18:52:42
ドキュメントはChangeLogとかも含むかな
666:デフォルトの名無しさん
09/08/04 00:06:50
作った香具師しか分からない様な糞コードだからドキュメントが必要。
cgi.rbなんて典型だろ。
667:デフォルトの名無しさん
09/08/04 00:09:35
きちんとしたドキュメントがあるのとないのとで、使い方から潜在的なバグの発見まで
どれだけ敷居が低くなるのかってことはあるはずなんだが。
そもそも人に使って貰うことを前提に公開・配布してるんと違うんかと。
668:デフォルトの名無しさん
09/08/04 00:55:56
cgi.rbが糞コードってのは公認なの？
俺がアホだから解りづらいのか、糞コードだから解りづらいのか、
どっちなのか悩んだ事があったんだが。
669:デフォルトの名無しさん
09/08/04 01:11:55
PerlのCGIモジュールの再実装だから、当然・・・。
670:デフォルトの名無しさん
09/08/04 01:58:15
あれは「これをもとにブラッシュアップする」という予定をすっ飛ばされたライブラリだから
cgi.rb 自体が悪いというよりは、それこそリリースエンジニアリングが悪い
671:デフォルトの名無しさん
09/08/04 02:15:08
そもそも「CGI汎用対応ライブラリ」は実装が汚くなる傾向にある
バージョン 0.2 くらいでは非常に理想的なコード進行なんだが、
バージョン 0.95 になると特殊条件割り込みやら外部バグ対応やらでぐちゃぐちゃに
672:デフォルトの名無しさん
09/08/04 02:37:35
ライブラリの中がある程度汚くなるのは仕方ない分野もあるってことかな
その分、APIの統一やらドキュメントの充実やらで対応するのが常道だろうけど
ソース嫁って意見はその辺はどう考えてるんだろうか
まさかコメントあるからおｋってことでも無かろうが
673:デフォルトの名無しさん
09/08/04 04:36:26
できれば標準ライブラリは一番綺麗なお手本でいてほしい。
その言語処理系でなにかしようとするなら、まず標準ライブラリを参考にするし。
ただ、「これをもとにブラッシュアップ」とか言ってたらオープンソースじゃ
一生リリースできないからね。何もないよりは、はやリリしょちゅリリのほうがいいよ。
ここでグダグダ言ってるよりか何か書いてパッチでも送りつけるorパッチ袋に
蓄積するというほうが現実的なんではないかな。あ、俺はやらないけどw
そんな暇あったら自分の仕事するしw
674:デフォルトの名無しさん
09/08/04 06:07:19
ちなみに、cgi.rbをブラッシュアップするぜと言ってメンテナになられた奇特な方がxibbarさんなので、
みなさん意見とか言ってあげてください
675:デフォルトの名無しさん
09/08/04 06:30:59
え、何が楽しいのとか馬鹿じゃねーのとか他のことやったらとかそういう意見でもいい？
676:デフォルトの名無しさん
09/08/04 06:35:53
WEBrickにセッション機能つけてcgi.rb捨てようぜ
677:デフォルトの名無しさん
09/08/04 08:23:39
むしろRackを標準にしてcgi.rbを捨てるのがいいんじゃね
あと、確か一時期cgialtに置き換えようって動きもあったよね
あれどうなったのかな
678:デフォルトの名無しさん
09/08/04 08:26:23
Rack は CGI 環境での動作テストをせずにガンガンリリースしまくったという負の実績が…
679:デフォルトの名無しさん
09/08/04 08:28:24
>>651
ｽﾚﾘﾝｸ(newsplus板)
680:デフォルトの名無しさん
09/08/04 08:48:59
>>678
それで1.0.0でもCGIが動かないという恐るべき状況になったのか
681:デフォルトの名無しさん
09/08/04 10:07:18
>>677
Ruby本体では、年1リリースでも支障がない程度に安定していることという暗黙の前提があるので、
Rackが入るにはもうしばらくかかるんじゃないかな。
たまに話が出るFFIも同様の理由で当分はない。
CGIAltにはすでに置き換わってるよ。
気づかなかったとしたらそれはxibbarさんが慎重にテストしながら置き換えた成果だね。
682:デフォルトの名無しさん
09/08/04 10:13:58
>>675
> え、何が楽しいのとか馬鹿じゃねーのとか他のことやったらとかそういう意見でもいい？
同旨の事は言った気がする（ぉ
683:デフォルトの名無しさん
09/08/04 10:29:43
ライブラリのソースを読んだ知見を元に何でドキュメントを書かないの？
684:デフォルトの名無しさん
09/08/04 10:39:36
ソースを読む才能とドキュメントを書く才能って別なんだよね。
リファレンスマニュアルならすでにあるし
685:デフォルトの名無しさん
09/08/04 10:43:36
それが理解できず開発者にドキュメントを強いる衆愚
686:デフォルトの名無しさん
09/08/04 11:16:57
引き篭もりはこれだから困る（）笑
現実の世界見てみろよ！
製作者が公演したり解説したり本書いたりするのが当たり前だから！
そして微妙な空気に支配される会場！がっかりが埋め尽くす書評！
無下にするわけにもハブるわけにもいかず仕方なく「スーパーバイザー」とかよくわからん横文字で濁されるお茶！
687:デフォルトの名無しさん
09/08/04 11:21:03
ああ、監修：ま何某ってそういう…
688:デフォルトの名無しさん
09/08/04 11:21:50
>>686
無知、乙
689:デフォルトの名無しさん
09/08/04 11:30:20
そういう役割分担というか、専門技能へのドライな眼差しは、
日本人が苦手としているところかもね。
スポーツでも、日本文化に古くから染み込みすぎて旧態依然としている分野（野球、相撲）ほど、
プレーヤーとトレーナー&マネージャーをごっちゃにするし。
690:デフォルトの名無しさん
09/08/04 11:30:34
>>686
関係者かなんか知らんけどあんな人無理に壇上で喋らせなくてもいいのに、と思うことはなくもない
せめて巷の体育の先生くらいには話のできる人がフォローすべき
インタビュー形式とか色々あんじゃんね
Ruby関係ないな
691:デフォルトの名無しさん
09/08/04 11:48:36
いや、あの公演、当日までスライドできて無くてアレしゃべってるんだぜ
すごい才能だと思わないか
いや、別にほめられた事じゃないけどさ
692:デフォルトの名無しさん
09/08/04 12:35:54
もちおみたいにオープンソースの理解も足りないんだろうな
あと、多くは開発者以外がドキュメントを書いている事実も。
Ruby 以外の言語も知っておくのは、そういう意味でも重要。
693:デフォルトの名無しさん
09/08/04 12:37:19
>>688=>>692
694:デフォルトの名無しさん
09/08/04 13:55:42
>>681
>CGIAltにはすでに置き換わってるよ。
ダウト
695:sage
09/08/04 15:11:48
>694
1.8系しか見てないのかな
696:デフォルトの名無しさん
09/08/04 15:17:46
>>694
おおう、たしかにCGIAltそのものではなかった
URLﾘﾝｸ(d.hatena.ne.jp)
697:デフォルトの名無しさん
09/08/06 22:06:18
IronRuby 0.9
698:デフォルトの名無しさん
09/08/06 23:01:11
IronRubyとJRuby、なぜ差がついたか… 資金、開発環境の違い・・・
699:デフォルトの名無しさん
09/08/06 23:24:23
>>698
どっちがいいの？
700:デフォルトの名無しさん
09/08/06 23:39:00
どっちも駄目
まだ
きちんと一定の形に完成しないのなら意味がない
701:デフォルトの名無しさん
09/08/06 23:41:59
JRubyは完成したとして何に使うのかがよくわからない
IronRubyはWin環境でのライブラリ不足を一挙に解決してくれるからな
702:デフォルトの名無しさん
09/08/07 00:01:12
ふと一行78文字ルールと戦うIronPythonデベロッパの姿が脳裏に浮かんだ
703:デフォルトの名無しさん
09/08/07 00:26:51
JRubyだってJavaのライブラリ使えるのが強みだろうさ
あとJVMが動く場所なら動くことと、JVMが速くなりゃJRubyも速くなること
704:デフォルトの名無しさん
09/08/07 04:03:18
1.9.1の最新版のmswin32のバイナリは出ないのだろうか・・・
705:デフォルトの名無しさん
09/08/07 08:33:10
>>700
「きちんと一定の形」についてもう少しkwsk
706:デフォルトの名無しさん
09/08/07 08:47:11
>>704
fURLﾘﾝｸ(ftp.ruby-lang.org)
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
なぜusaさんのページで出てないのかは謎
707:デフォルトの名無しさん
09/08/07 11:50:58
jrubyはもう駄目だろ Sunにさえ見放された
IronRubyは世界標準のWindowsだし、世界最強IT会社のMS製だし・・・
708:デフォルトの名無しさん
09/08/07 12:07:19
マイクロソフトが手を出せば成功するというのなら世の中はとっくに
709:デフォルトの名無しさん
09/08/07 12:26:30
Ruby の今後について、マーケティング用語「キャズム」を紹介する
URLﾘﾝｸ(www.mitsue.co.jp)
一般的にテクノロジーのライフサイクルはベル型の標準偏差のグラフによって示され、
その各段階でターゲットとすべき顧客として、イノベーター、アーリー・アドプ
ター、アーリー・マジョリティ、レイト・マジョリティ、ラガードといった顧客セグ
メントが行なわれます。通常、この顧客セグメントによって、異なるマーケティング
施策を行いながら、徐々に新しいテクノロジーの顧客層を広げていくことが推奨され
ます。しかし、米のマーケティング・コンサルタントであるジェフリー・ムーア氏が、
同名の著書によって、明らかにしたのは、イノベーターとアーリー・アドプター
で構成される初期市場と、アーリー・マジョリティやレイト・マジョリティによって
構成されるメジャー市場のあいだには、容易には越えがたい「キャズム（深いミ
ゾ）」あるということでした。顧客セグメントの違いによって生み出される、この
キャズムを超えなくては、新しい商品はメジャー市場でブレイクすることなく、規模
の小さな初期市場のなかでやがては消えていく運命となります。同著が、10年間にわ
たって米国ハイテク業界のバイブルとされたように、特にテクノロジーの進歩の激し
い業界においては、強く意識することが重要なマーケティング理論です。
以下は、マーケティングの視点で、Twitter の普及を分析
Twitter の快進撃がとまった!?～スローダウンの要因を分析する
URLﾘﾝｸ(japan.internet.com)
710:デフォルトの名無しさん
09/08/07 12:35:14
ふだんは Java と Ruby を両方いじっている者だが
(Java 系のエンジニアだが、さいきん Rails も覚えた)
Java のプロジェクト内ライブラリを叩く運用ツール(半使い捨て)を、
# たとえば 在庫一覧をファイルに出力するツールなど
いまは Java のプログラムでつくっているが、
これを JRuby でやるようにしたら、もっと手軽に作れないかなと思っている。
JRuby は、マルチスレッドプログラミングするなら Ruby 1.9 系よりも速いんじゃなかったっけ？
このスレだかどこかで読んだような
711:デフォルトの名無しさん
09/08/07 12:51:12
>710
そういうのは、Scalaでやった方がいいと思う。
712:デフォルトの名無しさん
09/08/07 13:12:29
>>710
Javaなら一応Groovyとかもあるかな
arton氏が似たようなシチュエーションでrake使って
自動化とか効率化とかやってたはず
713:710
09/08/07 13:17:10
>>712
Groovy は少しかじったけど、なんかいまいち。
Ruby のほうが見やすいし、Ruby / Groovy でできないところは Java で書く。
Groovy は Java しか出来ない人のスクリプト言語って感じだけど、Ruby 本物を覚えてしまった今、
いまいち中途半端だなあと感じる。
>>711
Scala でも使い捨てスクリプトをちゃちゃっと作れるのかな。
714:デフォルトの名無しさん
09/08/07 14:24:50
JRubyがもう少し起動早くなったらGUIが気持ちよくかけるかもしれない
715:デフォルトの名無しさん
09/08/07 17:19:04
>>713
そんなことない。
Groovyは最初からJavaと連携できるよう考慮されているから、Javaもよく使うならJRubyよりGroovyのほうがいい。
JRubyはあくまでRubyをJVMで使いたい人向け。
716:710
09/08/07 17:38:54
>>715
なるほど。
どうやら自分は、まだ Groovy への理解が足りないようだ。もうちょっと勉強してみるよ。
でも、るび厨になってしまったので、Ruby や JRuby いじっているほうが楽しいんだけどね。
717:デフォルトの名無しさん
09/08/07 21:53:14
あとGroovyは一時はJavaSDKに標準添付の話まであったのに
そのあと大きな動きがなくてプロジェクトが死んじゃってるんじゃねえの、って状態なのも難点かなあ
718:デフォルトの名無しさん
09/08/07 22:22:20
Groovyはコレの24p以降のイメージが強烈すぎた
URLﾘﾝｸ(kakutani.com)
719:デフォルトの名無しさん
09/08/07 23:21:26
おまえらのせいでGroovyに興味が湧いてきた
720:デフォルトの名無しさん
09/08/07 23:43:45
>718
なんだこれｗｗｗｗｗｗｗ
721:デフォルトの名無しさん
09/08/07 23:49:51
なついなあライブでみたよ
722:デフォルトの名無しさん
09/08/07 23:53:53
>>718
無駄に力作過ぎるが、全体を通してみてこれで使ってみたくなるか？という素朴な疑問
公平な紹介ってなんだろうけど
723:デフォルトの名無しさん
09/08/08 09:25:45
>>718
ネタ帳かとおもたwwwwwwww
724:デフォルトの名無しさん
09/08/08 09:28:03
弱点
● 機能セットがすべて出揃っていない
? 匿名インナークラスが未サポート（Groovy-1.1までに対応?)
? モダンなIDEでのサポートが不十分(Eclipse, IntelliJ...)
● 実行速度が遅い
? 対Java比: 20～90%
● デバッギング・ヘル!
? パーサが未成熟: わけのわからんエラーメッセージ
wwwwww
725:デフォルトの名無しさん
09/08/08 10:20:13
>>724
それ、いつのこと？現時点での話じゃないよね
726:デフォルトの名無しさん
09/08/08 11:37:41
>>725
>>718のPDFを見れば書いてあるよな
727:デフォルトの名無しさん
09/08/08 11:53:34
Ruby 初心者スレッド Part 30
ｽﾚﾘﾝｸ(tech板)
初心者スレが立ちました
アンチスレは落ちたままです
最終の遣り取りは以下の通り
> 979 名前：デフォルトの名無しさん [sage] 投稿日：2009/08/06(木) 19:50:29
> Ruby ってメモリ馬鹿食いするよね？
>
> 980 名前：デフォルトの名無しさん [sage] 投稿日：2009/08/06(木) 19:57:59
> まあ、そこそこには
> 省メモリで動作することが重要なのならRubyは使ってはいけない
728:デフォルトの名無しさん
09/08/08 12:41:08
>>726
>>>718のPDFを見れば書いてあるよな
それ、2004年の資料だよね。だから>>724は現時点での話じゃないよね。
おわかり？
729:デフォルトの名無しさん
09/08/08 12:51:02
別にいいけどおまえの言うことを
必死でくみ取ってくれる存在なんて両親くらいだぞ
730:デフォルトの名無しさん
09/08/08 13:14:14
Rubyの会のサイトって死んでるの？
解散した訳じゃないよね？
URLﾘﾝｸ(jp.rubyist.net)
731:デフォルトの名無しさん
09/08/08 13:35:53
>730
最近サーバの調子が悪いらしい
732:デフォルトの名無しさん
09/08/08 13:39:03
PJの社長みたいに金余ってる人がスポンサーにつかないものか
733:デフォルトの名無しさん
09/08/08 13:50:15
最近と言っても、ここ数日の話なので仕方ないと思われる。
734:デフォルトの名無しさん
09/08/08 17:07:25
1.8の方のDLってひょっとして可変長引数扱えないのかな。
ruby-ffiは出来るみたいだからそっちでごまかすかのう。
735:デフォルトの名無しさん
09/08/08 20:02:51
>>732
Ruby 界隈でイケメンはいないだろ
736:デフォルトの名無しさん
09/08/08 20:44:54
アンチスレも消えてすっきりしたな
737:デフォルトの名無しさん
09/08/08 23:09:44
>735
_why はイケメン。
738:デフォルトの名無しさん
09/08/08 23:50:23
これって既出ですかね？
Ruby1.9.1、Python3.1、Java1.6.0の実行速度比較
URLﾘﾝｸ(www.mwsoft.jp)
1.8は遅かったけど1.9はかなり速くなったと聞いてたので
そろそろRubyをしっかり勉強するのもありかなと思ってたんですが
この結果を見て愕然としました
何故にこれほど遅いんでしょう…
もう高速化の手段は残ってないんでしょうか…
739:デフォルトの名無しさん
09/08/08 23:59:25
WindowsでRubyって・・・
740:デフォルトの名無しさん
09/08/09 00:17:54
>>738
高速化技法はまだ全然試されていないからまだまだ伸び代はある。
Pythonも高速化計画が持ち上がってたはずだし。
741:デフォルトの名無しさん
09/08/09 00:18:17
そういえばRubyが遅い遅いとは言われてるけど
なんで（少なくともベンチマーク上では）遅いのか、その理由がよくわからない
1.9.1からYARVが入って、他の言語と同じバイトコンパイルになったはずだし
Pythonあたりと柔軟性で極端な違いがあるとも思えないし
742:デフォルトの名無しさん
09/08/09 00:19:57
>>738
きっきっと、新しいバージョンだから遅いいんだよ
最適化された・・・バージョンアナら・・・ぼぼろ負けはしないよ
>>739
LinuxにはPython入ってるから、Windowsで・・・
743:デフォルトの名無しさん
09/08/09 00:27:05
正直、じゃんごの日本語リファレンスとかもうちょっと充実してきたら
Pythonに移ってもいいかなって思ってる
744:デフォルトの名無しさん
09/08/09 00:31:09
俺は日本語リファレンスが充実しても、Pythonには行かないなー
Rubyが使いやすすぎて、ちょっとやそっとの速度差で止める気にはならない
どうしても速度が気になるなら拡張ライブラリがあるし
745:デフォルトの名無しさん
09/08/09 00:35:37
IronRubyによってMSが10倍速にしてくれるから気にするな
Linuxは知らん
746:デフォルトの名無しさん
09/08/09 00:36:34
>>745
その時には素敵な拡張文法がてんこ盛りだったりして
747:デフォルトの名無しさん
09/08/09 01:20:32
JRubyでいいじゃんはやいじゃん
748:デフォルトの名無しさん
09/08/09 01:46:45
とりあえずRubyがWindows上で遅い、特に一定の条件が揃うと妙に遅いというのは前から言われてる
あと、usa版バイナリはVC6でコンパイルしているので最適化が甘い
ので、まずはコンパイラを揃えてテストするべき
749:デフォルトの名無しさん
09/08/09 01:48:48
ということは、mingw版の方が速い可能性があるってことなのか
750:デフォルトの名無しさん
09/08/09 01:52:45
というか、Linuxサーバー上で運用されることが実際には多いんだから
Linuxでテストしないと意味がないと思うんだが・・・
Windowsサーバー使えるような企業やハイソサエティはRubyなんて使わんで
ASP.NET使うだろｊｋ・・・
751:デフォルトの名無しさん
09/08/09 07:46:33
> ということは、mingw版の方が速い可能性があるってことなのか
まぁ、それはあるけど、素直にVC9を使うのが楽だと思うよ
> Windowsサーバー使えるような企業やハイソサエティはRubyなんて使わんで
> ASP.NET使うだろｊｋ・・・
IronRubyをテストしてあげて！
752:デフォルトの名無しさん
09/08/09 09:02:21
>>751
またそんないばらの道を...
というかmingw32のほうがVC(9含めて)よりはやいというのは、以前からわかってる。
753:デフォルトの名無しさん
09/08/09 16:41:58
Windowsならgcc -O3で野良だろJK
754:デフォルトの名無しさん
09/08/09 16:46:52
Ruby/Tkさえコンパイルできるようになれば、すぐにmingw版に移るんだが
755:デフォルトの名無しさん
09/08/09 17:00:11
>>754
普通にできてるが
756:754
09/08/09 17:12:14
>>755
え、本当？
俺の環境では ruby-list:46093 と同じ問題でコンパイルできない・・・
何が問題なのかさっぱりだ
配布バイナリがあればそっちを使うんだけど、更新止まってるみたいだし
757:デフォルトの名無しさん
09/08/09 17:31:30
>>753
GCの関係で、最適化かけすぎると
不味いんじゃなかったっけ？
758:デフォルトの名無しさん
09/08/09 17:52:37
ソースコード完全解説には「-O2まで」と載ってるな
URLﾘﾝｸ(i.loveruby.net) （「最適化のヒント」の項）
759:デフォルトの名無しさん
09/08/09 18:45:58
>>758
むしろ-O3より-O2の方がコンパイルに時間がかかったって話も聞くけどな
760:デフォルトの名無しさん
09/08/09 19:01:57
The Computer Language Benchmarks Game
URLﾘﾝｸ(shootout.alioth.debian.org)
761:デフォルトの名無しさん
09/08/09 19:57:53
>>758
いつの時代の本だよ
762:デフォルトの名無しさん
09/08/09 21:22:36
いやgccの-O2と-O3の差とか、当時とそんなに変わってないし、
Rubyもevalこそ入れ替わったけど、GCは基本同じだし。
763:デフォルトの名無しさん
09/08/09 22:10:26
RHG1.9版出せよ
764:デフォルトの名無しさん
09/08/09 22:18:27
OneClickRubyInstaller の次期バージョンになる予定のRubyInstallerは、
mingw版です。ダウンロードできるけど、まだプレビュー版です。
URLﾘﾝｸ(rubyinstaller.org)
みんなでテストして、安定すれば問題解決じゃない？
1.8系はmingwにするだけで倍以上早くなるみたいだし。
URLﾘﾝｸ(antoniocangiano.com)
765:755
09/08/10 00:15:17
>>756
俺もstubはダメだったんで非stubで使ってる。
Tcl/Tk 8.5 以降できなくなったような気がする。
ちなみにActiveTcljは使ったこと無い。いつもソースからビルドしてる。
766:デフォルトの名無しさん
09/08/10 03:28:30
>>762
> いやgccの-O2と-O3の差とか、当時とそんなに変わってないし、
ソースだせソース
767:デフォルトの名無しさん
09/08/10 07:13:49
最近は-O3でも動くらしい（ソースはIRCでの中田さんの発言
768:デフォルトの名無しさん
09/08/10 08:37:56
もう1年以上-O3のRuby(MinGWとlinux)使ってるけど
特に問題になったことはないなあ
769:デフォルトの名無しさん
09/08/10 20:17:04
少なくとも写真はこっちが勝ちだな
「変わっていかなければ」。日本Rubyの会 会長の葛藤 － ＠IT自分戦略研究所
URLﾘﾝｸ(jibun.atmarkit.co.jp)
770:デフォルトの名無しさん
09/08/10 20:23:33
世界にはばたく日本のRuby（笑）から（笑）を取ってもいい頃合の状況なのに、
実際の中の人の活動は状況に比べて芳しくないんだよね
771:デフォルトの名無しさん
09/08/10 20:50:57
Javaの解説やドキュメントを書くのは楽しい
なぜなら、足りない部分を補填するという自覚がもてるからだ
Rubyの解説やドキュメントを書くのは楽しくない
なぜなら、余計なものを重複して書いてる気分になるからだ
Rubyのスクリプトコードがもうちょっと読みにくかったら
ドキュメンテーションへのインセンティブになると思う
772:デフォルトの名無しさん
09/08/10 23:57:13
> Javaの解説やドキュメントを書くのは楽しい
奇特な性癖の持ち主発見
773:デフォルトの名無しさん
09/08/11 01:02:30
内容から察するに、わざわざツッコミ入れなくてもそういう意味だと思うぞ
「Rubyに比べてJavaのコードは解りにくいから、むしろドキュメント書くのが楽しくなる」という内容のようだから
774:デフォルトの名無しさん
09/08/11 01:22:03
実際にはJavaでもろくに書いてないんだろうけどな
775:デフォルトの名無しさん
09/08/11 01:25:32
分かりきったことをあらためて書くことほどつまらないことはないので
気持ちはわからなくもない