Rubyについて Part 36 ..
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が爆速ってわけでもないのに
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5394日前に更新/227 KB
担当:undef