Rubyについて Part 36

1 ：デフォルトの名無しさん：2009/06/28(日) 16:29:28

オブジェクト指向スクリプト言語Rubyについて扱うスレッドです。
前スレに変なのが沸いて流れてしまいましたが、まったりと行きましょう。

Ruby Home Page
http://www.ruby-lang.org/ja/

= 前スレ
Rubyについて Part 35
http://pc12.2ch.net/test/read.cgi/tech/1238194350/

過去スレ・関連スレは >>2-

2 ：デフォルトの名無しさん：2009/06/28(日) 16:31:42

Rubyリファレンスマニュアル刷新計画
ttp://doc.loveruby.net/
ライブラリ一覧
ttp://doc.loveruby.net/refm/api/
RubyExtensionProgrammingGuide
ttp://i.loveruby.net/w/RubyExtensionProgrammingGuide.html
Ruby Hacking Guide
ttp://i.loveruby.net/ja/rhg/
Symbol < Stringも止める。
ttp://www.rubyist.net/~matz/20061107.html#p03
クラスローカルインスタンス変数
ttp://www.rubyist.net/~matz/20061117.html#p02
クラス変数
ttp://www.rubyist.net/~matz/20070104.html#p03
ローカル変数
ttp://www.rubyist.net/~matz/20070112.html#p04
可視性メモ
ttp://www.rubyist.net/~matz/20070208.html#p04
ttp://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/30107
ttp://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/30275
YARV without 1.9
ttp://www.rubyist.net/~matz/20070215.html#p01
ttp://www.atdot.net/~ko1/diary/200702.html#d22
ttp://i.loveruby.net/d/20070223.html#p01
JSON
ttp://json.rubyforge.org/
ttp://webos-goodies.jp/archives/51019710.html
ttp://webos-goodies.jp/archives/51071565.html
YAML
ttp://www.ruby-lang.org/ja/man/?cmd=view;name=YAML
ttp://jp.rubyist.net/magazine/?0009-YAML
ttp://www.namikilab.tuat.ac.jp/~sasada/prog/yaml.html

3 ：デフォルトの名無しさん：2009/06/28(日) 16:32:34

Ruby/Gtk+
ttp://www.unixuser.org/~haruyama/software/goRua/
ttp://takeposo.sakura.ne.jp/windows/environment/rubygtk.html
ttp://ruby-gnome.sourceforge.net/
ttp://ruby-gnome.sourceforge.net/programming/intro.html
ttp://ruby-gnome2.sourceforge.jp/
ttp://psux1.kek.jp/thitoshi/ruby/gtk/
ttp://www.rubycgi.org/ruby_gtk_book/
ttp://ruby.gfd-dennou.org/products/cygwin/index-j.html
ttp://www.magicianmaster.jp/tdiary/?date=20040912

4 ：デフォルトの名無しさん：2009/06/28(日) 16:33:29

Ruby on Rails
http://pc11.2ch.net/test/read.cgi/tech/1191381506/
ttp://jp.rubyist.net/magazine/?0004-RubyOnRails
ttp://www.onlamp.com/pub/a/onlamp/2005/06/09/rails_ajax.html
ttp://kyotosanga.com/gaku/archives/2006/01/ruby_on_rails_a.html
ttp://blog.hacklife.net/archives/50190377.html
ttp://www.metadata.co.jp/web20/ohba/060718_Rails/
ttp://japan.cnet.com/news/ent/story/0,2000056022,20089986,00.htm
ttp://japan.cnet.com/interview/story/0,2000055954,20094959,00.htm
ttp://journal.mycom.co.jp/articles/2006/07/31/radrails/
ttp://www.atmarkit.co.jp/fjava/column/andoh/andoh29.html
ttp://www.atmarkit.co.jp/fjava/column/andoh/andoh30.html
ttp://www-06.ibm.com/jp/developerworks/linux/050708/j_l-rubyrails.html
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20060209/228940/
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20060424/236113/

5 ：デフォルトの名無しさん：2009/06/28(日) 17:00:55

>>1-4
Rubyの残念さを象徴するようなわかりづらいテンプレだね
>>3,4とかもうURL羅列してあるだけで何がなんだか

6 ：デフォルトの名無しさん：2009/06/28(日) 17:07:36

「残念」って流行語なのか？

残念(笑)

7 ：デフォルトの名無しさん：2009/06/28(日) 17:25:19

>>1乙

テンプレは前回と同じじゃんか。
残念だと思ったら自分で整えて「次はこれで」って書き込めばいい。
世の中に不満があるならほかでやれよ。

8 ：デフォルトの名無しさん：2009/06/28(日) 18:02:48

前スレ最後まで必死でワラタｗ

9 ：デフォルトの名無しさん：2009/06/28(日) 18:18:47

このスレタイでよく続くな

10 ：デフォルトの名無しさん：2009/06/28(日) 18:42:29

それだけマイナーだし。

11 ：デフォルトの名無しさん：2009/06/28(日) 19:14:49

>>7
こんなわかりづらいテンプレに疑問を持たないようなユーザーがRuby使いです

12 ：デフォルトの名無しさん：2009/06/28(日) 19:28:32

実践CommonLispって本で
(deftest test-+ ()
　(check
　　(= (+ 1 2) 3)
　　(= (+ 1 2 3) 6)))
(deftest test-* ()
　(check
　　(= (* 2 2) 4)))
(deftest test-arithmetic ()
　(combine-results
　　(test-+)
　　(test-*)))
(deftest math ()
　(test-arithmetic))
って書くと
pass ... (MATH TEST-ARITHMETIC TEST-+): (= (+ 1 2) 3)
pass ... (MATH TEST-ARITHMETIC TEST-+): (= (+ 1 2 3) 6)
pass ... (MATH TEST-ARITHMETIC TEST-*): (= (* 2 2) 4)
みたいに関数テストができるユニットテストをつくるってネタがあったんだけど
これrubyでかくとどんなかんじになるのかな？

13 ：デフォルトの名無しさん：2009/06/28(日) 19:32:05

>>11
文句付けるなら具体的に案を出せば？

14 ：デフォルトの名無しさん：2009/06/28(日) 20:19:54

>>12
？
LISPよくわからんが、読める人は逐語的に書けばいいんじゃないの？
単なるユニットテストの超簡易サンプルだろ？
てかLISPって知らない人間に取っては暗号以外の何者でもないな。

15 ：デフォルトの名無しさん：2009/06/28(日) 21:36:25

>>14
rubyっぽくかくとこんな感じ。

deftest test_plus
　assert_equal(1+1, 2)
　...
end

deftest test_arithmetic
　test_plus
end

deftest test_math
　test_math
end

ってかいてtest_mathを呼ぶと
pass ... test_math test_arithmetic test_plus　: assert_equal(1+1 ,2)
みたくテスト内容と階層と結果を自動的に表示してくれるという
lispではこれをdeftestとかっていうマクロから書き始めても二十行くらいでかけてびっくりした。

英語版がここに公開されてる
http://gigamonkeys.com/book/practical-building-a-unit-test-framework.html

16 ：デフォルトの名無しさん：2009/06/28(日) 21:51:00

>>15
Lisp向きの処理をわざわざRubyに置き換えても無意味
糞言語がゲロ言語になるだけ

17 ：デフォルトの名無しさん：2009/06/28(日) 21:56:30

糞よりはゲロのほうがとか思ってしまった俺オワタ

>>12
まずは自分で書いてみな
置き換えること自体は無意味でも勉強にはなる

18 ：デフォルトの名無しさん：2009/06/28(日) 23:21:09

>>12
まず、
> pass ... (MATH TEST-ARITHMETIC TEST ～～
この出力が何に由来するものか理解できない俺は、Rubyでのコードもまったく想像できない。

って>>15のサイト見てたら、それはそれで定義するのかよｗ
# ゴルフネタなのか？それならPerlでもJavaScriptでもなんでも変わらないような以下略
今ひとつピントがわからない俺に易しい解説ｷﾎﾞﾝ

19 ：デフォルトの名無しさん：2009/06/29(月) 00:00:58

16bit CRCを求めるライブラリって標準でついてないの？

20 ：12：2009/06/29(月) 00:35:55

要するにテストの階層化が簡単にできるって話。
assert_equalに該当するようなcheckっていう関数（マクロ）を作って
deftestっていう関数定義のようなものをテスト用に作って
deftestで、例えば足し算のテストをする。test_plusっていうのを定義して、
その中でcheck(1+1==2)みたくテストを書く。
で実行すると「test_plusから呼ばれたcheckの1+1==2っていう式は真/偽だったよ」
って教えてくれるわけ。
さらにdeftestでtest_arithmeticを定義してその中でtest_plusを呼ぶと
「test_arithmeticから呼ばれたtest_plusから呼ばれたcheckの1+1==2っていう式は真/偽だったよ」
と教えてくれる。さらにdeftestでtest_mathを定義してその中でtest_arithmeticを呼ぶと……
みたいに階層化することができる。さらにそれぞれの関数ですべてのテストが真だったか/ひとつ以上偽だったか
の結果を返すので、

「test_arithmeticから呼ばれたtest_plusから呼ばれたcheckの1+1==2っていう式は真だったよ」
「test_arithmeticから呼ばれたtest_plusから呼ばれたcheckの1+9==10っていう式は真だったよ」
「test_arithmeticから呼ばれたtest_timesから呼ばれたcheckの1*1==1っていう式は真だったよ」
すべてのテストは成功しました。

みたいに関数名とか階層とか評価した式とかをいちいち別に書かなくても表示してくれる。
それでこれと似たようなことをrubyで書けるかなっと少し考えてみたんだけどさっぱり思いつかない。

21 ：デフォルトの名無しさん：2009/06/29(月) 00:48:50

>>19
Zlibにあったような気がしたが、CRC32だな。
githubにCRC16が落ちてたからそれで我慢して。

22 ：デフォルトの名無しさん：2009/06/29(月) 00:49:32

階層化とやらの実装はcaller調べりゃすぐ出来る
むしろ最終的に実行した式(1+1=2とか)を表示する部分に工夫が必要

23 ：デフォルトの名無しさん：2009/06/29(月) 06:23:05

そもそもLISPとか括弧だらけで美しくない
レベルの低い話をRubyのスレに持ちこまないで

24 ：デフォルトの名無しさん：2009/06/29(月) 06:38:33

>>20
今ひとつ掴み切れんが、RSpecの階層化で幸せになれる話？

context 'arithmetic' do
　context 'plus' do
　　specify '1+1' do
　　end

　　specify '1+9' do
　　end
　end

　context 'times' do
　　specify '1*1' do
　　end
　end
end

実行した式の表示に関しては、Rubyではまず無理だろう
その芸当は「手続きも含めてすべてがデータ（リスト）」のLispだからこそだ

25 ：デフォルトの名無しさん：2009/06/29(月) 07:46:46

無理やりやるとしたらこんなか？何か気持ち悪いなあ

def check(recv, method, *args)
　expect = args.pop
　backtrace = raise rescue $@
　result = recv.send(method, *args)
　うんたらかんたら
end
check(1, :+, 1, 2)

26 ：デフォルトの名無しさん：2009/06/29(月) 09:54:34

GitHubで、有名じゃないRubyライブラリのプロジェクトをいじって遊んでる
足りないテストがあるので追加してるんだが、
ユーザー指定のわりとレアな組み合わせによっては期待通り動作しないことがわかった
ライブラリ側を直せばいいんだが、これを直すと確実に大改造になるし、
ライブラリを利用してる既存スクリプトの動作も下手すると変わってしまうし、
正しく直せたかどうかがいまいち俺にはわからん分野でもある

　A 現状追認のテストだけ書いて、不動作関連は記述せず、別途報告
　B 現状追認のテストだけ書いて、不動作関連は記述せず、報告もしないで見なかったことに
　C テストを実行するとテスト失敗になるようにしておいて、不動作は別途報告
　D テストを実行するとテスト失敗になるようにしておいて、不動作は無視
　E 「BUG：本当はテスト失敗になります」と書いて、失敗結果を出すことを成功とみなしてテストは通す

どうしましょ

27 ：デフォルトの名無しさん：2009/06/29(月) 10:03:41

そういや、GitHubでむちゃくちゃ大量にすっごいアドホックなコード追加して
「みんなの見つけてないバグ見つけたのでなおしときましたー」って言ってくる人はいる

そんなコミット怖くてマージできんわー
そんな怖いコード書くくらいならひとまず現象の報告だけして改正案募ってくれ
「どうすればいいかわからんがとりあえずやるか」といったときのコードはたいていあとで問題を起こす

ということで、A

28 ：デフォルトの名無しさん：2009/06/29(月) 13:09:37

>>24
evalでねじ込めば実現できなくもない・・・・・・

29 ：デフォルトの名無しさん：2009/06/29(月) 16:11:54

びっくり最小にするためにアグレッシブに進化してるな。
http://codezine.jp/article/detail/4052

30 ：デフォルトの名無しさん：2009/06/29(月) 19:13:36

Pythonのことあんま知らんけど、intとlongの互換性ってどんなんだったん？
Rubyの場合、FixnumとBignumはほとんどシームレスだけど

31 ：デフォルトの名無しさん：2009/06/29(月) 19:19:00

なんつーか、Rubyやってる奴ってRubyしかできないんだよな
だから>>12みたいに毛色の違う関数型言語の話題が来ても誰もついていけないという…

32 ：デフォルトの名無しさん：2009/06/29(月) 19:41:20

それはまあ言語歴、プログラミング歴によるのでー

33 ：デフォルトの名無しさん：2009/06/29(月) 19:41:22

LISP やっているやつはこんなのばっか。

34 ：デフォルトの名無しさん：2009/06/29(月) 19:54:54

C言語やJavaやってる人間がいきなり>>12見ても理解不能だろ・・・常識的に考えて

35 ：デフォルトの名無しさん：2009/06/29(月) 20:00:20

C#から満を持して飛び込んできましたがサッパリです

36 ：デフォルトの名無しさん：2009/06/29(月) 20:07:29

SICP読んだ事があるのに分からんかった。

37 ：デフォルトの名無しさん：2009/06/29(月) 20:08:44

解説いらないなら本書く理由も無いからな

38 ：デフォルトの名無しさん：2009/06/29(月) 20:21:26

PL/SQLで頼む

39 ：デフォルトの名無しさん：2009/06/29(月) 20:43:42

>>31
そうそう。逆にPHP使える奴はPerlもHaskellも楽勝だったりする。

40 ：デフォルトの名無しさん：2009/06/29(月) 20:49:03

誰にも構ってもらえてないのか？

41 ：デフォルトの名無しさん：2009/06/29(月) 20:49:13

>>39
ダウト

42 ：デフォルトの名無しさん：2009/06/29(月) 20:51:36

>>39
×PHP
○Python

43 ：デフォルトの名無しさん：2009/06/29(月) 20:52:14

Rubyに限らず他言語を一つでも知ってればlispなんて１日で読めるようになるよ。

44 ：デフォルトの名無しさん：2009/06/29(月) 20:53:39

>>42
それは単純にPython厨に古い人が多くてRuby厨に新しい人が多いってだけだろｗ
古い人は経験豊富なんだから他言語習得するも簡単

45 ：デフォルトの名無しさん：2009/06/29(月) 20:56:15

PythonはLispのパクリだから親和性が高いのが特徴

46 ：デフォルトの名無しさん：2009/06/29(月) 21:01:19

Ruby会議いくやついる？
あれって、チケット必要なのね。
とっくに売りきれてたorz.

47 ：デフォルトの名無しさん：2009/06/29(月) 21:02:41

RubyにもCommon Lisp成分が入ってると思うが
触ってみると、なるほどご先祖様だと感じられる
Matzが参考にしてると言うだけはある

48 ：デフォルトの名無しさん：2009/06/29(月) 21:05:26

>>39
それはないだろw

49 ：デフォルトの名無しさん：2009/06/29(月) 21:12:04

Ruby も Python も LISP も信者はおかしなのが多い。

50 ：デフォルトの名無しさん：2009/06/29(月) 21:13:46

隔離スレあるんだからいい加減そっち行ったら？

51 ：デフォルトの名無しさん：2009/06/29(月) 21:26:02

>>20
実行結果出力例が納得いかないんだが、test-arithmeticの結果、mathの結果、は別途表示されないの？

それはともかく、

deftest "test_plus" do
　check ["1+2", 3], ["1+2+3", 6]
end
deftest "test_times" do
　check ["2*2", 4]
end
deftest "test_arithmetic" do
　combine_results "test_plus", "test_times"
end
deftest "math" do
　test_arithmetic
end

に対して

pass ... (math test_arithmetic test_plus): 1+2 == 3
pass ... (math test_arithmetic test_plus): 1+2+3 == 6
pass ... (math test_arithmetic test_times): 2*2 == 4

と表示させるテストライブラリくらいはあっという間に書けた。

52 ：デフォルトの名無しさん：2009/06/29(月) 21:33:00

evalかな
そうだとすると、違わないんだけどなんか違うようなやっぱり違わないような
なんだこの無形の障壁は

53 ：デフォルトの名無しさん：2009/06/29(月) 22:04:34

evalです。
作ってみて思ったんだが、>>52の気持ちはよくわかる、というか、対象式を表示させるために文字列で渡してevalするという発想自体が捻じ曲がってる気はする。

54 ：デフォルトの名無しさん：2009/06/29(月) 22:26:43

構文木を直接書き下すlispはそこんとこ突き抜けてるからな。

55 ：デフォルトの名無しさん：2009/06/29(月) 22:30:23

１年ほど前からスピードランニングやってます。
貧乏なので生活費辛くなってPart9で中断してますが。。

率直な感想を言えば、内容は悪くないと思う。聞きやすいしバックのクラシック音楽も意外に効果的。
ただ、会話がいかにも教材のために作られたという感じの内容なのでつまらなくてすぐに飽きます。
例えば、日本人と外国人が映画に行って、お互いの文化を説明しあったりとか。
価格は高すぎると思う。ちゃんと机で教科書開いて学習する意思がある人ならNHKラジオの英語教材買った方が遥かにお得だし効果的。
１年ぐらいの間暇を見つけてはCD聴いてたわけですが、現時点で英語の映画とか観ても相変わらずほとんど聞き取れない。
効果が出るかは謎。出るにしても時間はかかるんだろうなぁ

56 ：デフォルトの名無しさん：2009/06/29(月) 22:31:14

↑誤爆した。すまん

57 ：12：2009/06/29(月) 22:31:20

>>51
まさにそんなかんじ。すげー
でも勉強不足なもんでそのdeftestの実装がどうなってるか
よくわからん。
checkは文字列を引数としてあとでevalするのか。なるほど

58 ：デフォルトの名無しさん：2009/06/30(火) 01:19:50

Proc#to_sあたりでコード片の文字列に戻せたならeval避けられそうなんだけどね

例えばJavaScriptだとユーザー定義の関数は
（インデント等の差違はあるけど）Function#toStringでコード片に戻せる

rubyの実装だとこういうの難しいんだろうか

>>47
Array#cdrあったような気がしてつい探したことがあるｗ
・・・昔あったんだっけ？

59 ：デフォルトの名無しさん：2009/06/30(火) 06:52:46

いいかげんウザいよ

60 ：デフォルトの名無しさん：2009/06/30(火) 10:25:45

お前はなんの話題なら納得するんだ

61 ：デフォルトの名無しさん：2009/06/30(火) 12:11:29

まぁ、Array#cdrなんて無くても ary[1..-1]で済むからなぁｗ

62 ：デフォルトの名無しさん：2009/06/30(火) 12:33:45

>>57
実装はこんな感じ。5分ほどで書いたから汚くてごめん。
class Test
　@@tests = []
　def check(*tests)
　　name = caller[0...-2].reverse.map{|str| str.sub(/\A.*`(.*)'\z/){$1}}.find_all{|m| @@tests.include?(m)}.join(' ') #`
　　tests.flatten.each_slice(2) do |expression, expected|
　　　result = eval(expression) == expected
　　　puts "#{result ? 'pass' : 'failed'} ... (#{name}): #{expression} == #{expected}"
　　end
　end
　def combine_results(*cases)
　　result = true
　　cases.each do |c|
　　　result = false unless send c
　　end
　　result
　end
　def self.run
　　self.new.__send__ @@tests.last
　end
end
def deftest(name, &block)
　Test.class_eval "
　　define_method(name, block)
　　@@tests.push(name)
　"
end
END {
　Test.run
}

63 ：デフォルトの名無しさん：2009/06/30(火) 13:07:24

> 5分ほどで書いたから汚くてごめん。
謝るくらいなら5時間できれいなものを書け

64 ：デフォルトの名無しさん：2009/06/30(火) 13:28:35

2chのレスのために5時間かけるくらいなら、５分で書いてゴメンするほうを選ぶわな。
みんながみんな、2chに張り付いているわけじゃない。63みたいに。

65 ：デフォルトの名無しさん：2009/06/30(火) 13:29:48

なんで1円にもならんことに5時間もかけにゃならんのだ。

66 ：デフォルトの名無しさん：2009/06/30(火) 13:36:37

>>64-65
だったら一々言い訳つけて女々しいレスすんな

67 ：デフォルトの名無しさん：2009/06/30(火) 13:42:14

こいつ前スレの>>971だろ
酷い劣等感だ

68 ：デフォルトの名無しさん：2009/06/30(火) 14:12:26

Ruby ユーザの脳味噌の中身は PHP みたいですね

69 ：デフォルトの名無しさん：2009/06/30(火) 22:19:01

>>67
そんなわけないだろ。
ちなみに前スレでやり合ってたのもおれじゃない。
監視する価値を感じなくなったからもう書き込むことはないよ。じゃあ

70 ：デフォルトの名無しさん：2009/06/30(火) 22:24:37

ここまで我慢してたけど監視する価値でﾌｲﾀ

71 ：デフォルトの名無しさん：2009/06/30(火) 22:32:29

watchの機械翻訳かもな
外国のお客さんは大事にするべきかもよ

72 ：デフォルトの名無しさん：2009/07/01(水) 00:41:49

るびまきてるね、編集乙
だが松江Ruby会議と仙台Ruby会議は福岡開催じゃNEEEE

73 ：デフォルトの名無しさん：2009/07/01(水) 01:52:16

>>72
ワロタｗｗｗ
広島Ruby会議も栃木で開催されてるよ！

74 ：デフォルトの名無しさん：2009/07/01(水) 02:19:50

Ruby会議って面白いですか？
「はじめてのRuby」を一通り読んだ程度の人間が行っても場違いでしょうか？

75 ：デフォルトの名無しさん：2009/07/01(水) 05:30:43

教祖に有って、誤利益の有るツボとか買いたければ参加してみるのも一興。

76 ：デフォルトの名無しさん：2009/07/01(水) 06:54:36

>>72-73
普段どういうコードを書いてるか目に浮かぶようだ

77 ：デフォルトの名無しさん：2009/07/01(水) 10:11:31

Ruby ユーザの質は PHP みたいですね

78 ：デフォルトの名無しさん：2009/07/01(水) 11:12:35

>>77
仲の悪い奴らを一緒に語ると、変なのが湧いてくるからやめてくれ。

79 ：デフォルトの名無しさん：2009/07/01(水) 14:31:17

そもそもperlの再発明だしね。

80 ：デフォルトの名無しさん：2009/07/01(水) 15:24:28

rubyはperlの…とは良く言われるが、一体rubyのどこがperlな訳？
perlオリジナルの機能でrubyが模倣したモノって何よ？

81 ：デフォルトの名無しさん：2009/07/01(水) 15:25:40

>>80
模倣じゃなくて劣化再発明
だからRubyはPerlではないし、Perlの代わりにはならない

82 ：デフォルトの名無しさん：2009/07/01(水) 15:40:54

やっぱり無いんだ、そもそもperlこそがパクリ言語だもんな
そーゆー意味では劣化再発明と言うのは当たってるか

83 ：デフォルトの名無しさん：2009/07/01(水) 16:01:39

RubyがBlack PerlをパクってZen of Rubyを隠しコマンドに入れたのは超有名

84 ：デフォルトの名無しさん：2009/07/01(水) 16:51:33

コマンドラインオプションとかif/unless修飾子とかredoとかだってグーグル先生が
あとperlが出典かわかんないけど、メソッドだと同じ名前のものが腐るほどあるよな

85 ：デフォルトの名無しさん：2009/07/01(水) 18:37:48

他の言語からも取り込みまくってるから、perlと特に似てるって感じではない
いろいろな言語のいろいろな特徴・アイデアを取り込んだのがRuby

強いて言えば、主な用途（スクリプティング、文字列処理、Web）がperlと似てるか

>>83
詳しく

86 ：デフォルトの名無しさん：2009/07/01(水) 22:57:04

perlっぽい使い方を想定してる所は有るね。
松本教祖謹製perlってところか。

87 ：デフォルトの名無しさん：2009/07/01(水) 23:38:09

perlパクってるくせに
perlからの脱却とか言ってperlの悪口ばかり言ってるのも面白いよね

88 ：デフォルトの名無しさん：2009/07/01(水) 23:47:24

>>87
こんなところにまでわざわざご苦労様です

89 ：デフォルトの名無しさん：2009/07/01(水) 23:49:07

rubyはawkのパクり。

90 ：デフォルトの名無しさん：2009/07/01(水) 23:54:52

とりあえず国産言語だから、という理由で覚えてみてる。
scala見たいな別の言語が出てきたら使いたいなー

91 ：デフォルトの名無しさん：2009/07/02(木) 00:46:08

でも国産言語だと世界でメジャーじゃないのがねえ。

主要OSが英語圏で作られてるから、利用環境が充実しない。
plやpyと比べると(ry

92 ：デフォルトの名無しさん：2009/07/02(木) 00:59:57

むしろ国産言語じゃ世界的に普及しまっくてる方じゃね？

93 ：デフォルトの名無しさん：2009/07/02(木) 01:03:09

>>87
だからperlからパクったものをあげてみろって
今んとこ出てるのはif,unless(while,until)修飾子とredoな
# 関数名とメソッド名が似通ってるのはUNIX文化から来てるからperlは関係ない

どうせperlもrubyも他の言語もロクに使ったこと無いんだろ？

94 ：デフォルトの名無しさん：2009/07/02(木) 01:10:03

>>92
まがりなりにも世界的に利用者のある国産言語と言われても思いつかない
KL/1ぐらい？Prologの世界では有名なのかも分からんが、
とてもメジャーとは言いがたいと思う

95 ：デフォルトの名無しさん：2009/07/02(木) 01:18:19

お堅い洋書を読んでいてもRubyの名前は当然のように出てくるぞ

>>93
pack/unpack, shift/unshiftなんかはPerl起源っぽくない？

96 ：94：2009/07/02(木) 01:20:54

あああRubyを除いての話

97 ：デフォルトの名無しさん：2009/07/02(木) 01:52:35

>>94
Lisp 界隈だと KCL (Kyoto Common Lisp) とか ISLISP くらいかねえ
まあ、 KCL は言語じゃなくて処理系だし、 ISLISP は ISO 標準のわりにあまり見掛けないけど

98 ：デフォルトの名無しさん：2009/07/02(木) 05:02:39

>>95
その手の関数はC等で良く使われる手法を、perlでは言語標準にしただけだと思う
perlの関数はunix-cやawkの関数がそのまま使われてるし、他の言語もだいたい同じ
むしろ同じ機能なのにわざわざ別の名前にされても憶えるのが面倒だし混乱の元だから
パクリと言われても同じ名前をつけてくれる方が使う側としてはありがたい

99 ：デフォルトの名無しさん：2009/07/02(木) 06:00:57

Rubyは国産でも日本語対応がいいわけじゃないから何のメリットもないよ

> Ruby(ルビー) †
> 日本産ではあるが日本語の取り扱いは他の言語と同レベルで、特にRubyとしてのアドバンテージはない。

100 ：デフォルトの名無しさん：2009/07/02(木) 06:32:18

標準で日本語の文字コード変換機能を備えてる訳でもないしな。

101 ：デフォルトの名無しさん：2009/07/02(木) 09:12:18

>>99-100
(　ﾟдﾟ)ﾎﾟｶｰﾝ

102 ：デフォルトの名無しさん：2009/07/02(木) 09:23:08

>>100は皮肉だろ。たぶん

103 ：デフォルトの名無しさん：2009/07/02(木) 10:45:01

>>93
コマンドラインオプションは既に出てるでしょ。
あと、特殊変数の類はほぼ全部perl由来だね。
それに絡んで、Kernelの一部のメソッド類が$_を特別扱いするのもperl由来。

104 ：デフォルトの名無しさん：2009/07/02(木) 12:05:42

> 日本産ではあるが日本語の取り扱いは他の言語と同レベルで、特にRubyとしてのアドバンテージはない。

どこからの引用だそれ？

1.8 までの文字列は 8 ビットスルーで、どんな文字コードでもトラブらないように
作られてるし、1.9 の i18n は、文字コードフェチの夢実装屋の悪夢の CSI が
実現されてるしで、日本語対応は他のスクリプト言語と比べて特徴的な所
なんだが。

検索したら、プログラミングスレまとめ in VIP、かよ。
訂正してやる気も失せる VIP クオリティだな。

105 ：デフォルトの名無しさん：2009/07/02(木) 12:12:31

パクっただのなんだのなんてネタは前世紀で終わらせとけよｗ

106 ：デフォルトの名無しさん：2009/07/02(木) 12:59:23

なぜこんなに多くの人が日本語の扱いに困っているんだろう。
それを考えてみることも必要。

107 ：デフォルトの名無しさん：2009/07/02(木) 13:01:13

> 多くの人が日本語の扱いに困っている

困ってるのか？

108 ：デフォルトの名無しさん：2009/07/02(木) 13:12:38

>>106
バカだからだろw

109 ：デフォルトの名無しさん：2009/07/02(木) 13:23:37

Ruby ユーザの日本語の認識は PHP の mb_* 並ですね

110 ：デフォルトの名無しさん：2009/07/02(木) 13:41:08

辞書順ソートが標準でできないとダメとか言いたいのか？

111 ：デフォルトの名無しさん：2009/07/02(木) 17:51:07

>>87
スリップストリームに使う車体は
追い抜くためにありますので。

112 ：デフォルトの名無しさん：2009/07/02(木) 23:21:01

>>104
> 日本語対応は他のスクリプト言語と比べて特徴的な所
日本語対応…？
対応…？

113 ：デフォルトの名無しさん：2009/07/03(金) 01:06:20

JISで統一すれば良かったのに、EUCとかSJISを使い続けるのを許してた。
結局、UTFなんて新しいコードがもう一つ増えたしなあ。
欧米だと、utfとascii/iso8859がちゃんとマップしている。

114 ：デフォルトの名無しさん：2009/07/03(金) 01:10:23

今さら去年のRubyConfでのmatzの基調講演を見たが、
ことさらloveだとか強調されるとキモい

115 ：デフォルトの名無しさん：2009/07/03(金) 01:49:57

Ruby愛を語った講演というと、むしろRuby会議2007のDave Thomasを連想する
生で見たことはないが、ニコニコ動画に転がってたと思う
ユーモアたっぷりにRubyを語ってるのは面白かったｗ

116 ：デフォルトの名無しさん：2009/07/03(金) 02:00:56

C(++)系のプログラマに pack/unpack を直感的に理解してもらう
うまい説明の仕方ってあるだろうか？

117 ：デフォルトの名無しさん：2009/07/03(金) 02:17:19

>116
ソースコードを読ませる。

118 ：デフォルトの名無しさん：2009/07/03(金) 02:35:41

>>116
Cで構造体なんかをfread/writeするコードと
Rubyでpack/unpackするコードを並べて見せればいいじゃまいか

119 ：デフォルトの名無しさん：2009/07/03(金) 04:04:30

char* <=> struct* のキャストにbase64等の便利機能を加えた物、とか

120 ：デフォルトの名無しさん：2009/07/03(金) 08:49:39

それCで書けるなら、Cのほうがいいって結論に成る。
おまいらだと、rubyで書ける事をわざわざCで書かないだろ。

121 ：デフォルトの名無しさん：2009/07/03(金) 08:51:15

むしろC/C++プログラマの方が理解しやすいだろ
ネイティブのintとかエンディアンがどうこうとか日常だし

122 ：デフォルトの名無しさん：2009/07/03(金) 09:51:45

この論点のずれ具合が巨大掲示板の醍醐味。

123 ：デフォルトの名無しさん：2009/07/03(金) 10:42:33

pack/unpackなんて実質的にCプログラマのための機能だろう。
直感的にもなにも、C構造体そのものやん。

124 ：デフォルトの名無しさん：2009/07/03(金) 12:23:48

すいません。どなたか、初心者スレたててください(´･ω･`)
おながいします

125 ：デフォルトの名無しさん：2009/07/03(金) 12:32:03

>>123
あれはRubyらしく操作するということをハナから放棄したシロモノだよね

新しく再構成したRuby専用インタフェースを覚えなおすのとかめんどくさいから流用というのもあるんだろうけど

126 ：デフォルトの名無しさん：2009/07/03(金) 12:41:00

初心者スレって意味あるのか？

127 ：デフォルトの名無しさん：2009/07/03(金) 12:44:48

そりゃ初心者は一定数いるだろうし、
初心者が卒業する一方で新しい初心者も出てくるだろうし
大抵の言語スレで初心者スレがあるのを見ても、あったほうがいいんでない

128 ：デフォルトの名無しさん：2009/07/03(金) 12:54:14

スレ立てトライしてみる

129 ：デフォルトの名無しさん：2009/07/03(金) 12:58:46

Ruby 初心者スレッド Part 29
http://pc12.2ch.net/test/read.cgi/tech/1246593305/

130 ：デフォルトの名無しさん：2009/07/03(金) 13:01:50

乙

131 ：デフォルトの名無しさん：2009/07/03(金) 14:28:28

>>113
EUC-JPもShift_JISもJISベースですがなにか

132 ：デフォルトの名無しさん：2009/07/03(金) 15:08:43

だから何なのかサッパリわからんレスの最後に、なにか、とか書かれてもな。

133 ：デフォルトの名無しさん：2009/07/04(土) 12:13:23

Shift_JIS と名乗って CP932 の文字使ってる Web ページは爆発しろ
あと～と〜でどうにかなるページももれなく爆発しろ

134 ：デフォルトの名無しさん：2009/07/04(土) 14:33:05

どか～ん

135 ：デフォルトの名無しさん：2009/07/04(土) 14:46:00

ラテン文字入ってるのに us-ascii と名乗ってるページがあるのと同じようなもんかな、と思うことにしてる

136 ：デフォルトの名無しさん：2009/07/04(土) 17:59:45

何も言わないと、iso8859が仕様ですがなにか？

137 ：デフォルトの名無しさん：2009/07/04(土) 18:10:17

ラテン文字てーと
ABCDEFHIKLMNOPQRSTVWXZ
こうですか。Gもか。

138 ：デフォルトの名無しさん：2009/07/04(土) 18:16:28

>>136
US-ASCIIって名乗ってるって言ってるじゃん

139 ：デフォルトの名無しさん：2009/07/07(火) 09:34:04

しつもんー
Ruby は外部 iconv のバージョンとか構成とか関知してないよね
WINDOWS-31J が使えない Iconv モジュールとか存在しうるよね
でも SHIFT_JIS は期待していいよね

140 ：デフォルトの名無しさん：2009/07/07(火) 09:45:11

ttp://www.gnu.org/software/libiconv/
> Japanese
> 　　EUC-JP, SHIFT_JIS, CP932, ISO-2022-JP, ISO-2022-JP-2, ISO-2022-JP-1

この6つは存在するものとして扱っていいと思う

これ以外はシステムに存在しなかったときのエラー処理が要るな
エラー処理ったって何すればいいのかさっぱりわからんが(w
自前で変換表持って置換でもすればいいのか？

141 ：デフォルトの名無しさん：2009/07/07(火) 20:46:44

ISO-2022-JP系で使ってるようなエンコーディングを
外部とのデータ交換用ではなく内部で使おうとするのは
かなり技術的なセンスが欠落してるよな

まだ昔のX-Multiがやってたような
独自の固定長のコード体系の方がマシというか

142 ：デフォルトの名無しさん：2009/07/07(火) 20:48:51

メール前提だと文字化けしない事が重要なので、一切変換せず扱えるのも大きい。
バイト文字列として扱えば良いけどね。

143 ：デフォルトの名無しさん：2009/07/08(水) 00:03:58

これからの時代は文字コードはUnicode系しか認めん。
みんながテキストファイルをUTF-8にしておけば文字コード関係のトラブルは格段に減るのに。

144 ：デフォルトの名無しさん：2009/07/08(水) 00:19:07

メール程度の日本語を使いたいだけならUTF-8一択で問題が極小になるという
現代の真実が主流になるのは一体いつのことだろう。
Outlookか？Thunderbirdか？鶴亀か？Beckyか？正直何が悪いんだ？

145 ：デフォルトの名無しさん：2009/07/08(水) 08:33:31

フォントとグリフと文字集合とエンコーディングを分けて話さないと
CSIの怖い人がきそうだな

146 ：デフォルトの名無しさん：2009/07/08(水) 09:09:34

文字集合とエンコーディングとcharsetを区別して
（定義を暗誦するとかではなく）日常的に使える人は日本で一握りだろうな

147 ：デフォルトの名無しさん：2009/07/08(水) 10:42:18

言語と用字(スクリプト)の区別とかもだねー。

148 ：デフォルトの名無しさん：2009/07/08(水) 23:31:08

オブジェクト指向だと、メソッドの長さは１５行程度ってえらそうな人が書いてたですが
そんなものなの？…

149 ：デフォルトの名無しさん：2009/07/08(水) 23:41:37

>>148
そうとは限らないが、たいてい短い方が好ましいのは確か

とはいえ、重要なのは「処理内容がきちんとメソッドに分割されているかどうか」だから
長さそのものが問題になるわけではない

150 ：デフォルトの名無しさん：2009/07/09(木) 00:10:03

なるほど…しっかり分割していけば、だいたいその程度に収まる事が多い
という感じか・・・

151 ：デフォルトの名無しさん：2009/07/09(木) 00:18:58

javaはクラスやメソッドが長いって馬鹿にするやつが多いけど
あれはeclipseで補完するもんなのにわかってないおん

152 ：デフォルトの名無しさん：2009/07/09(木) 00:32:54

補完機能つきの重量級IDEを使わないと仕事にならないということですね、分かります

153 ：デフォルトの名無しさん：2009/07/09(木) 00:42:23

しかしIDEでの補完を使えば、LL言語よりも生産性は上がる。
なにしろ、変数の型付けが厳格で、定義していない変数は使えないから、
単純なミスタイプなら、遅くともコンパイルする段階で防げる。
これはちょっとしたことのようでかなり大きい。

154 ：デフォルトの名無しさん：2009/07/09(木) 00:55:12

>LL言語よりも生産性は上がる
問題の種類による。ウォーターフォールで仕様策をガッチリきめて
作り始めるならともかく、形を考えながらプロトタイプを
チャッチャと作ってすぐ練り直す問題（今はほとんどがこれ）だと
LL言語のほうがメリットが大きい。

鶏を裁くのに牛刀を使う必要はないってこと。

155 ：デフォルトの名無しさん：2009/07/09(木) 01:01:34

LL言語て

156 ：デフォルトの名無しさん：2009/07/09(木) 01:04:36

牛刀で鶏なんて表現知らなかった・・・
あまりに上手いこと言えてて誰かの名言か何かと思えば故事だったのか

157 ：デフォルトの名無しさん：2009/07/09(木) 01:11:20

漏れが知ってるぐらいだから結構知られてる表現じゃないか

>>155
AST木ってのを見たことがある

158 ：デフォルトの名無しさん：2009/07/09(木) 01:47:56

RAS症候群はわかりやすい意思疎通を行おうとする正常な人間の証だろ

そういうことを言い出すと、
DVDディスクとか、IT技術とか、LCDディスプレイとかBB弾とか
HIVウィルスとかBS放送とかもダメになる。そんな馬鹿なことはあるまい。

159 ：デフォルトの名無しさん：2009/07/09(木) 02:06:11

>>158
ほう、現在のDVDが何の略かご存知とお見受けする
ぜひ御教えを請いたいものだ

160 ：デフォルトの名無しさん：2009/07/09(木) 02:27:42

今のDVDはDVDの3文字を擁する規格だからな
まーどうでもいいっちゃどうでもいいが
あと「LL言語」は日本語としては普通
LLとだけ書かれてもよーわからんし、読むときもLの部分だけ訳して考えてなどおるまいて

プログラムとしてではなくプログラミング最中の静的言語のメリットは完全な補完ができることだろ
Rubyの補完なんて文脈なしで文字列としてしかできんからへぼいことこのうえない
まあそれでもけっこうなんとかなるこたなるんだが、Javaのようなものとは比べるべくもない

161 ：デフォルトの名無しさん：2009/07/09(木) 03:18:01

「軽量言語」でええじゃろ

162 ：デフォルトの名無しさん：2009/07/09(木) 06:52:36

普通にLLつってるな。
文脈でわかるもんだし。

163 ：デフォルトの名無しさん：2009/07/09(木) 07:14:23

LLと呼び習わされる言語群、という程度の意味合いしか持たせてないからLL言語と言ってる
そんな引っかかるほど頻繁に使う言葉じゃないし

セミナとかで使いまくってるような人はまた違う感覚があるのだろう

164 ：デフォルトの名無しさん：2009/07/09(木) 11:05:35

>>151
名前の長さの話なんか誰もしてないぞ。

165 ：デフォルトの名無しさん：2009/07/09(木) 11:14:11

>>151ではないが名前の長さのことなんて言ってないと思うぞ

RubyでもIDEを使えばけっこう構文エラーチェックがされて楽だけどな

166 ：デフォルトの名無しさん：2009/07/09(木) 11:26:13

Java の Eclipse に負けている Ruby の emacs/vi の機能ってなに？

167 ：デフォルトの名無しさん：2009/07/09(木) 11:39:09

>>166
はやーい

168 ：デフォルトの名無しさん：2009/07/09(木) 11:57:41

eclipse のほうが遅い

169 ：デフォルトの名無しさん：2009/07/09(木) 12:05:47

Emacs や vim のほうがエディタとしての体をなしている、というあたりだな

べつに、Eclipce で完結してるならそれはそれでいいじゃんね
Emacs や vim を試して「○○機能がないからこれではプログラミングできない」と考えたなら使わなきゃいいんだしさ

170 ：デフォルトの名無しさん：2009/07/09(木) 12:37:02

irbでのタブによるオートコンプリートやvimのオムニ補完が存在することから考えれば、
rubyをはじめとしたスクリプト系言語でもabbrev以上のレベルの補完機能は
普通に需要があると思うけどね

動的言語ゆえの実装の難しさから実装例が少ないだけの話を
「LLに補完は不要」といわんばかりの主張にすりかえちゃうのは
いわゆる酸っぱいブドウでしかないよねえ

171 ：デフォルトの名無しさん：2009/07/09(木) 12:46:58

irbのは実行中のインスタンスバイナリが手元に存在してるからできる芸当だろ

あるクラスに対して略語展開以上の妥当なメソッド名や変数名候補を提供するには
「クラスの実際のパースとモジュール参照の解決だけを行うがインスタンス生成はしない」
ということをする必要があるが、それはつまり普通にスクリプトの実行だよな

172 ：デフォルトの名無しさん：2009/07/09(木) 12:56:21

もっと言っちゃうと、
「区別のために関数名を長くして、
　使用時の利便性は環境による補完などのアシストで補う」
っていうアプローチって、静的言語によく使われている手法ではあるけど、
そもそもの元祖ってLISPのREPLだからむしろ動的言語側から
発生したアイデアなんだよねw

関数名を長くするか小さくするかなんて言語を利用する際の
考え方の違いでしかなくて、
動的か静的かなんて観点とは直交なんだけど、
歴史を知らない人って目先の相違点で近視眼的に敵味方を分けちゃうんだよねー。

173 ：デフォルトの名無しさん：2009/07/09(木) 12:58:41

えー、

class C
eval("def hoge; end")
end

C.new.

この時点で hoge が候補に出てきて欲しいということ？

174 ：デフォルトの名無しさん：2009/07/09(木) 13:05:06

>>173
それが出ないのはさすがに諦めていいんじゃないかと思う。

175 ：デフォルトの名無しさん：2009/07/09(木) 13:10:09

じゃあ何が自動で出て欲しいのよ
require した完成済みのクラスやモジュールのメソッド？
作ってる最中のコンパイルエラーのクラスのメソッド？
今まさに書いてる引数に指定してもエラーを起こさない妥当なクラスが入ってる変数名？

176 ：デフォルトの名無しさん：2009/07/09(木) 13:10:54

実際Netbeansは内蔵のjrubyで解析かけてるし、vimもrubyと連携してオムニ補完してるんだけどね。

実用上役に立つレベルにもっていくにあたって
エディタのコードハイライトみたいなお手軽な実装量で済まないのは確かだけど、
やれば出来るし、動く現物が今存在するわけだしねえ。

そもそも補完に完璧を目指す必要なんかなくて、
使用する際の8割でアシストが出来るなら5倍の効率化だし、
9割効くなら10倍の効率化になるわけだし。

177 ：デフォルトの名無しさん：2009/07/09(木) 13:17:59

> require した完成済みのクラスやモジュールのメソッド？
これは ri あたりから引いてくるのが既にあるな
fastri が動作しなくなって久しいが

> 作ってる最中のコンパイルエラーのクラスのメソッド？
変な書き方してると補完試すたびにスクリプト片が中途半端に動作して
テストサーバに接続とかそういうことが起きそうで怖い
というか現在のバッファに書いてあるなら動的略語展開でなんとかならんか

> 今まさに書いてる引数に指定してもエラーを起こさない妥当なクラスが入ってる変数名？
これは無理だろ、型の情報がない

178 ：デフォルトの名無しさん：2009/07/09(木) 13:25:21

>>177が最近の技術に疎いだけというオチがつく悪寒
vimの奴のソースでも見てみたらいいんじゃね?

179 ：デフォルトの名無しさん：2009/07/09(木) 13:29:02

そのへんで楽したいなら無理せずにJavaやれよJava
静的言語は素晴らしいって実感するぞ

180 ：デフォルトの名無しさん：2009/07/09(木) 13:31:00

Java をずっとやってきて、動的言語の素晴らしさを実感しているけど？
用途によるね。

181 ：デフォルトの名無しさん：2009/07/09(木) 13:35:09

Rubyでメソッド引数の型をアノテーションか何かで註記する標準的な方法って
無いの？
いくら動的型だからって、或る程度想定してるクラスの範囲ってあるでしょ？

182 ：デフォルトの名無しさん：2009/07/09(木) 13:37:45

>>181
マジでなんもないよ
必要なメソッドさえ動作すれば何でもいいから

マニュアル的に注釈をする方法は、マニュアルシステムによっては存在するけど、案の定全く流行ってない

183 ：デフォルトの名無しさん：2009/07/09(木) 13:41:53

よくわからんけど、
Eclipse(Aptana Rad Rails)より Netbeans Ruby のほうが、
補完の候補が出てくるのが速い気がする。

184 ：デフォルトの名無しさん：2009/07/09(木) 13:43:59

まあメソッド定義から与えられた引数がどう使われるか（どんなメッセージがsendされるか）
追跡して、引き数に指定できる変数を絞り込むぐらいなら出来る。

method_missing使ってどうこうしてるようなケースじゃ厳しいが。
まあ完璧である必要もないしな。

185 ：デフォルトの名無しさん：2009/07/09(木) 13:53:54

>182
えーと、逆に言えば、メジャーなマニュアルシステムを選べば、
標準的とまでは言わないまでも、まぁまぁ一般的な型の註記法があるって感じ？
例えば？

186 ：デフォルトの名無しさん：2009/07/09(木) 13:55:27

>>182
yard流行ってないよね
ttp://yard.soen.ca/getting_started
最初はきちんとクラスを書いていたものの「Rubyだとホントはどんなクラスでもいいんじゃね？？」とか
気づいてしまった人が多いのではないかと推測

# 挨拶する
#
# @param [String] name 挨拶する対象
def hello(name)
　puts "hello, #{name}"
end

# 家にいるかどうかをチェック
#
# @return [true, false] 家にいるかどうかの真偽値
def at_home?
　# check
end

187 ：デフォルトの名無しさん：2009/07/09(木) 14:04:09

>>186
yardoc の引数のはたくさん書かなきゃいけなくなるからめんどくさくなるんだよ
each で回せればなんでもいい場合は [#each] とも書けるが、必要なメソッドったって結構あるしなー

188 ：デフォルトの名無しさん：2009/07/09(木) 14:08:32

マニュアル書くのめんどいメソッドは駄目メソッドという教育効果が

189 ：デフォルトの名無しさん：2009/07/09(木) 14:13:24

>186
それはわざわざ書き方がめんどくさいのを選んでるせいかも？

ScalaかHaskell的なシグネチャが有れば十分じゃない？
その例で言えば、こんな感じ
hello : String => nil　# Scala的書法
hello : {def to_s: String} => nil 　# ScalaのStructual Typing的書法
hello :: String -> nil # Haskell的書法

190 ：デフォルトの名無しさん：2009/07/09(木) 16:01:31

is_a? ではなく respond_to? で制限をかけることを思いついた
が、使うメソッド全列挙がめんどいのでやっぱり駄目だな

191 ：デフォルトの名無しさん：2009/07/09(木) 16:20:01

respondで縛ると結局JavaのXXXableインターフェースみたいになっちゃうからね

指定が煩雑な割に完全に型が決定できるわけでもないから
JavaのうれしくないところとRubyのうれしくないところが悪魔合体したような有様に

192 ：デフォルトの名無しさん：2009/07/09(木) 16:30:29

phpunit なら PHPDoc をある程度自動生成するのにね
yardoc を生成するのを作ったら

193 ：デフォルトの名無しさん：2009/07/09(木) 16:51:54

いや、その、なんていうかだな、yard の @params のクラス名称の8割くらいの用途は、
実は引数の名称で用が済むんだよ

引数の名称に data とか e とか使いまくってるならまだしも、
普通は相当の意味のある引数名になってるだろ

　def hoge(str, params)

って書いてあったら、str はよっぽどでなけりゃ String だし、
params は意表をつく攻撃をする意図がなければたいてい Hash だろ
それ以上の情報は @params のクラス名称でもわからんわけだしな

194 ：デフォルトの名無しさん：2009/07/09(木) 17:02:31

それゆえに真面目にyardを書いても大してうれしくないという話になり、
今のまんまでいいじゃん、でここまで来たのが現状だからなあ

195 ：デフォルトの名無しさん：2009/07/09(木) 17:12:54

変数名に「str」ってハンガリアン記法の問題そのままだなｗ

196 ：デフォルトの名無しさん：2009/07/09(木) 17:18:59

yardoc の一番よくないところは、必死でクラスを書いても現時点で特にメリットがないということ
このクラスを利用して補完がうまく動くぜーということも特になく、マニュアルの行が1個増えるだけ

マニュアルを読むときの話なのなら説明文やそれこそ引数名を直接読んでもらえれば
クラス名なんて不完全な情報だけどころか意図まで全部わかるわけだ

197 ：デフォルトの名無しさん：2009/07/09(木) 17:23:55

>>195
title_string_or_empry_when_tag_contains_nothing_or_nil_when_tag_itself_doesnt_exist_called_by_HTMLParser_ParsedData_title とか
そういう一発で内容がわかるほうがいっすか

198 ：デフォルトの名無しさん：2009/07/09(木) 17:30:40

>>196
まあrdocの代表的な実装が、メソッド名クリックとかで
該当部分のソースを見れるようになってるのが
その辺の現実を如実に示してるよね。

>>197
責務を分割しろとかパッケージ化して共通の修飾部を外せとか言われるんじゃね
つうかstrが文字列だとわかると嬉しいのかどうかってのがよしあしの分岐点だよな

199 ：デフォルトの名無しさん：2009/07/09(木) 17:39:45

// i に 100 を代入する
i = 100;

のような「見ればわかることまでいちいち書かんでええ」系のツッコミの適用範囲が
Ruby ではえらい広いから
どこまでコメント書くべきなのか書かなくてもいいもんかちょっと迷う

200 ：デフォルトの名無しさん：2009/07/09(木) 18:02:25

>>197
意味分からない。

ハンガリアン記法と同じ問題を抱えてると具体的に書いたのだが、
なんでそんなに見当違いのレスがくるんだ？

201 ：デフォルトの名無しさん：2009/07/09(木) 18:13:01

CやJavaのような強く型付けされた言語と違って、引数の型情報のないLLでは
引数の名前に型名情報を加えたほうが使いやすい場合も多いだろう。
Smalltalkだと、aString, anEvent, aRectangle, xNumber, yNumberみたいに書いたもんだ。
この場合は、変数の役割よりも型名のほうが偉い。

202 ：デフォルトの名無しさん：2009/07/09(木) 18:58:07

引数にstrをとるメソッドが文字列処理のヘルパークラスみたいに
strの内容が文字列でさえあれば問題なくなにがしか処理できるのなら
引数名はstrで必要にして充分だよな。

逆に引数の内容が何らかの意味のある文字列であって、
想定外の内容だったときにはエラーを返さなきゃいけないような処理なんであれば、
その「想定している何か」の情報を引数名に込めてやりたいところ。

203 ：デフォルトの名無しさん：2009/07/09(木) 18:59:23

まああと Smalltalk の場合はクラス名の部分を選択してクラスの説明読んだり
クラスブラウザ立ち上げてブラウズしたりって意味もあるけどねって話はいいとして、
名前をつけるので迷いがちなら、ケント・ベック読んでおけばとりあえず指針は得られる。

http://www.amazon.co.jp/dp/4894717549

204 ：デフォルトの名無しさん：2009/07/09(木) 19:10:01

ケントベック本というと、読んだ後に引数名を
aTarget
とかにしまくってしまうような偏見がある

205 ：デフォルトの名無しさん：2009/07/09(木) 21:12:14

Smalltalk の場合は、引数の名前の他にキーワードセレクタも引数の使い方を表す情報として使用できる。
この使い方は、Rubyのメソッドが引数をハッシュでとる場合に近い。
ハッシュのキーに意味を持たせれば、値の名前は要らない。

206 ：デフォルトの名無しさん：2009/07/10(金) 01:10:26

「その、まあ」なやつは前RAIDスレにいなかったか？今もいるかもしれんが

207 ：デフォルトの名無しさん：2009/07/10(金) 08:48:47

ttp://github.com/tenderlove/mechanize/commit/fa8d725fabcabd2c1dbaf9e9c9700890fafba81f
うへえ、90KBのソースファイル全部から一番外側のモジュール定義を物理的に引っこ抜いて、
一番最後に空のモジュール作って再代入しよった
っていうかこんなんgithubでやるな、追随や衝突解決がめんどくさいから
どうせ「スペースがもったいない」「インデントが深いから」とかいうアホな理由だろこれ

module WWW
　class Mechanize
　　def …
　　class Page
　　　def …
　　end
　end
end

　　　　　　　↓

class Mechanize
　def …
　class Page
　　def …
　end
end
module WWW; end
WWW::Mechanize = ::Mechanize

208 ：デフォルトの名無しさん：2009/07/10(金) 09:00:33

「いっちゃん外側の纏め用モジュールの扱い」ってのは難儀なとこではある
ここにはメソッドも定数も定義されず、クラスをまとめるモジュール空間の提供としてのみ存在するもの

インデント深くなるから外に出しちゃえってのはそれはそれでいいんじゃないの
WWW::Mechanize と Mechanize の2つが存在することになるから WWW モジュール作った意味なさそうだけどさ

てんだらーが nokogiri 疲れでトチ狂ったのかと思ったら別の人の直接コミットなのね

209 ：デフォルトの名無しさん：2009/07/10(金) 09:11:47

この場合は ::Mechanize でアクセスできなくすればいいんだろ
…方法思いつかんが
なんかある？

210 ：デフォルトの名無しさん：2009/07/10(金) 10:19:37

これずううううううっと思ってたんだけどさ、オフィシャルページの HTML のタイトルさ、
「ダウンロード」とか「ニュース」とか単語になってるのなんとかなんね？
「Ruby ダウンロード」とか「ニュース - オブジェクト指向スクリプト言語Ruby」とか
他のサイトと区別できるタイトルつけようぜ

211 ：デフォルトの名無しさん：2009/07/10(金) 10:22:55

Object.send(:remove_const, 'Mechanize') とか

212 ：デフォルトの名無しさん：2009/07/10(金) 10:51:30

それは WWW::Mechanize ごとアクセスできなくなるんでは…

class Mechanize; end
module WWW; end
WWW::Mechanize = ::Mechanize
Object.__send__(:remove_const, 'Mechanize')
p Mechanize.new rescue "Mechanize.new.failed"
p WWW::Mechanize.new rescue "WWW::Mechanize.new.failed"

"Mechanize.new.failed"
#<Mechanize:0xb7cfaec4>

んぬう

213 ：デフォルトの名無しさん：2009/07/10(金) 11:08:50

クラス名は単なる定数で、参照先がたまたまクラスオブジェクトだってことさ。

214 ：デフォルトの名無しさん：2009/07/10(金) 11:14:11

>>210
チラシの裏に提案を書いてもどうにもならないことは自覚してる？

215 ：デフォルトの名無しさん：2009/07/10(金) 11:14:32

class Hoge
end

と書いたとして、これがいつ class クラスのオブジェクトとして存在し始めるかというのは意識しにくいかもね

216 ：デフォルトの名無しさん：2009/07/10(金) 11:25:48

__send__でprivate呼べなくなったんじゃなかったっけ

>>215
class ～ endがself返せばirbとかでわかりやすいんだろうけど

ってこれも他のブロックのように最後の返値を返すのか
class Foo; end #=> nil
class Bar; self; end #=> Bar

217 ：デフォルトの名無しさん：2009/07/10(金) 11:59:30

WWW::Mechanize = ::Mechanize

これさ、あたりまえだけど
WWW::Mechanize.name
の返値は
"Mechanize" のままなんだな。

素直に
module WWW; class Mechanize; end; end
した場合は
"WWW::Mechanize"

218 ：デフォルトの名無しさん：2009/07/10(金) 12:23:37

Structといい、一応ファーストクラスオブジェクトなのに
そのへんの仕様で足引っ張ってる感じだｗ

219 ：デフォルトの名無しさん：2009/07/10(金) 12:45:52

とりあえず、この変更にはユーザーデメリットしかないと思う
俺としてはMechanizeが下手打ってくれて有難いが

220 ：デフォルトの名無しさん：2009/07/10(金) 12:50:29

うっさいよhttpclient

221 ：デフォルトの名無しさん：2009/07/10(金) 12:55:00

今は Anemone かも
あれはASCII 文字使い以外には機能が不足しまくりで、基本機能揃えて実際の現実フォローを行うと
単に Mechanize になるだけなんじゃねともっぱらの評判

222 ：デフォルトの名無しさん：2009/07/10(金) 16:23:46

>>214
それを「気にして」いるのは君だけだよ

223 ：デフォルトの名無しさん：2009/07/10(金) 16:36:05

エスパー参上

224 ：デフォルトの名無しさん：2009/07/10(金) 18:22:16

>>209
module WWW; end
class WWW::Mechanize
end

225 ：デフォルトの名無しさん：2009/07/10(金) 19:40:18

>>220
HTTPのクライアントなんだけどさ、
①HTTP/HTTPSが使えて
②GET/POSTその他メソッドのレスポンスを
　サーバからクライアントへの全文の受信を待たずに
　ある程度の大きさの塊で順次受け取れて
③Windows（mswin32）で動く
ライブラリってなんかあるかな?

①、②までならlibcurlのRubyバインディングのcurbがあるんだけど、
curbはドキュメントでLinux以外想定してないと明記されてるわ
mingwでgem installしてみたら案の定拡張ライブラリのコンパイルで
引っかかるわで、
今泣きながらDL経由でlibcurl叩こうとしてるんだけど。

226 ：デフォルトの名無しさん：2009/07/10(金) 19:50:15

>>225
つまり net/http を使わないってことね

227 ：デフォルトの名無しさん：2009/07/10(金) 20:04:26

>>226
うん。net/httpだと②が出来ないと思う。

意図としては、サーバ側から取得してくるリソースが
典型的なHTMLみたいに数KB～数100KB程度のサイズの場合は
内容を全部取得してからまとめて処理してもいいんだけど、
動画みたいな数MB～数100MB程度のサイズの場合は
頭から数10KBとか数100KB程度の大きさでいいから順次取得して
逐次処理したいんだ。

228 ：デフォルトの名無しさん：2009/07/10(金) 22:04:04

>>227
>動画みたいな数MB～数100MB程度のサイズの場合は
>頭から数10KBとか数100KB程度の大きさでいいから順次取得して
>逐次処理したいんだ。

動画じゃないけど、おなじようなことをしたいです。
これってRubyでやるときは、どんな設計にするのがいいの？

229 ：デフォルトの名無しさん：2009/07/10(金) 22:06:37

不用意にnet/httpを使わない
サーバが対応してるなら、こっから100キロバイトぶんだけくれというHTTPヘッダを送りつけ続ける

230 ：デフォルトの名無しさん：2009/07/10(金) 22:13:31

net/http は逐次処理させるの自体はできた気がする
ただ、どう小細工しても「取得完了時にメモリを数百MB占有」というのは回避できない

231 ：デフォルトの名無しさん：2009/07/10(金) 22:18:25

そういえばopen-uriなんかでもコールバック設定できたよね
ダウンロード状況の進捗とか示すのに使うやつ
逐次処理だけできればいいのならそれで足りそうな気が

232 ：デフォルトの名無しさん：2009/07/10(金) 22:21:33

>>227
230も言ってるけど、逐次処理できるよ
HTTP#getにブロックを渡せばいい
（HTTP.getではできないので注意）

233 ：225,227：2009/07/10(金) 22:24:01

>>229
ご存じの通り、Rangeヘッダでの取得だとサーバ側がパーシャルで返してくれなかったときに寒いことに。
で、net/httpを一部いじったりしてレスポンスのボディをある程度逐次に取れるようにしても、
単純な実装だとkeepaliveとかpipelineとかが絡んできたときにcontent-lengthやらchunkやらの取り扱いで面倒なことに。

>>228
Linuxで動けばいいのならcurbのon_bodyがそのまんま。
あらかじめコールバックハンドラ用のprocを登録しておくと、
目的のURLにアクセスしてレスポンスのbodyをある程度受け取ったタイミングで
受け取ったデータを引数にしてprocを呼んでくれる。

eventmachine使うとクライアント的な動作についてもイベントドリブンな感じで
実装できるっぽいけど、一から作るのもな、という。
実際目的が同じかはともかくほぼ一から作ろうとしてる人もいるみたいだけど。
ttp://blog.masuidrive.jp/index.php/2008/08/07/how-to-write-spider-using-eventmachine/

234 ：225,227：2009/07/10(金) 22:30:51

>>232
おお。もっかい確認してみます。

結局作りたいモノって大した物じゃなくて、
手元にあるmouseHoleもどきのHTTPプロキシに
ttp://www.artonx.org/diary/20090301.html
みたいな仕掛けを仕込みたいってだけなんですが。

235 ：デフォルトの名無しさん：2009/07/11(土) 21:11:56

いよいよAndroidの国内端末（HT-03A）出たね
これでRuby動かしてみた人居る？

236 ：デフォルトの名無しさん：2009/07/13(月) 10:45:37

ruby/tkのビルドで自動でライブラリさがしてくれるようになったね＞nagaiさん乙でした
でも、makeにすっごく時間がかかるようにもなってしまった。

237 ：デフォルトの名無しさん：2009/07/16(木) 04:57:23

p Time.at(100).strftime("%H:%M:%S") => "01:01:40"

これで "00:01:40"を返して欲しいんですが
時間は常に +1 されて帰ってくるんでしょうか？

238 ：デフォルトの名無しさん：2009/07/16(木) 05:33:56

TZ=UTC0 ruby -e'p Time.at(100).strftime("%H:%M:%S")'
"00:01:40"

時差+1ってことはフランスかどっかにお住まいですか。Merci

239 ：デフォルトの名無しさん：2009/07/16(木) 05:43:31

>>238
ああっ標準時刻とのずれか！
9時間なら気づけたのに！

場所はドイツからです。 Danke schön!!

240 ：デフォルトの名無しさん：2009/07/17(金) 20:43:15

Ruby 会議、初日行ってきたお
通訳しているレオさん(?) かっこよすぎる

声もイカす

・自分はずーっと大講堂だったが、高井さんのエンタープライズRailsがおもしろかった
　ヨドバシに並ぶようになったらポイントで買おう
・外人さんがけっこう見かけた

241 ：デフォルトの名無しさん：2009/07/17(金) 22:04:15

>>240
オレはずっと１Ｆだったが、ささだ研がブラック研究室ということが分かったよかったｗ

242 ：デフォルトの名無しさん：2009/07/17(金) 23:09:01

懇親会でアーロンがおよげたいやきくん歌ってた。

243 ：デフォルトの名無しさん：2009/07/17(金) 23:38:33

わざわざ日本に着てまで喋るだけあるな……

244 ：240：2009/07/18(土) 01:32:36

終わったあと、新宿でエヴァ破をひとりで見てから帰ってきた。

>>241
笹田さんって Ruby 1.9 の YARV を作っている方だよね？
そのセッションも聞きたかったのだが、Rails 3 のほうを聞いていたので聞けなかった。
ブラックだったのか.....

明日も早起きしないと。

245 ：デフォルトの名無しさん：2009/07/18(土) 09:24:17

>>242
ひげの山男さんマジぱねえっす（日本に馴染んでる的な意味で）

246 ：デフォルトの名無しさん：2009/07/18(土) 14:04:03

>>244
昨日午前中見てきた

247 ：デフォルトの名無しさん：2009/07/18(土) 14:04:50

> ブラックだったのか.....
あれはまぁ自虐ネタだから

248 ：デフォルトの名無しさん：2009/07/19(日) 00:36:45

レオさんは俺の嫁

今日の1Fの最後のコマ(GC)にいたんだけど、
Ruby 本体のメンテナ(コミッタ)は、ほぼ日本人ばかりなの？
外人さんもいるの？

あるいは Linux Kernel みたいにパッチは世界中から受け付けるけど、
コミッタは日本人だけなのかな？

249 ：デフォルトの名無しさん：2009/07/19(日) 01:38:29

>>248
ttp://yugui.jp/articles/833

日本人が多いけど、外人さんもいる様子
有名な人だと、Dave ThomasとかDavid Flanaganとか

250 ：デフォルトの名無しさん：2009/07/19(日) 16:35:21

実際に誰が動いているかとかはコミットログやChangeLogみるとか、
「Ruby のコミット数ランキング」を見るとか。
http://dame.dyndns.org/misc/ruby-commit-ranking/

まぁ、Rubyってあんまりパッチ来ないかなぁ、受け付けてはいるんだけどね。
Ruby内部のコードを読んで、いろいろつっこみをしてくる外人さんって、
Ruby本を書いているから細かいところまで見ているってイメージがある。
あと、パッチが外から来づらい理由として、継続して送ってくる人には
コミット権をあげちゃうからってのもあるかな。

251 ：デフォルトの名無しさん：2009/07/19(日) 23:01:55

ブラック研究室に入ったんだがどうやら俺は限界らしい
http://www.ci.i.u-tokyo.ac.jp/~sasada/

映画化決定

252 ：デフォルトの名無しさん：2009/07/19(日) 23:04:02

日本Rubyの会公式Wiki - 日本Ruby会議2009 アンケート
http://jp.rubyist.net/?Enquete2009

アンケートを書くまでがRuby会議です。

253 ：デフォルトの名無しさん：2009/07/20(月) 17:09:14

プレゼンはustreamのrecordedでもうほとんど見れるんだな、すげー時代だ
kwatchのいうテンプレートとAOPってのがamritaとどこが違うのかわからんかった
スレでtenjinのアピールしてたのっていつごろだったっけ

254 ：デフォルトの名無しさん：2009/07/20(月) 18:45:13

AOPはJavaでは比較的知られているけど、たしかにHTMLテンプレートと絡ませると面白いかも。

255 ：デフォルトの名無しさん：2009/07/20(月) 18:50:16

AOPってなに？
アスペクト指向とかいう現状バズワードまがいの代物ですか？

256 ：デフォルトの名無しさん：2009/07/20(月) 18:56:43

バズワードだってｗ
使ってみたかったんだねｗ

257 ：デフォルトの名無しさん：2009/07/20(月) 19:58:59

そういえば、matzが言ってたnloopパッチって
結局何で適用されないんだろう

高速化は正直どうでもいいけど、
多重ループが圧縮できるのは嬉しいと思うんだけどなあ
ネストが浅くなるし、行数も減るし

258 ：デフォルトの名無しさん：2009/07/20(月) 23:22:08

名前とか？
nloopでは分かりづらくね

259 ：デフォルトの名無しさん：2009/07/22(水) 00:57:45

今時は、なんでもeco。
名前にecoを付ければ、政府援助が付いて、双方ウマウマ。
なわけで、
ecoloop
おいらは、実態を知らんが、高速になるならecoに違いない。

260 ：デフォルトの名無しさん：2009/07/22(水) 06:58:47

>>255
>アスペクト指向とかいう現状バズワードまがいの代物ですか？

アスペクト指向は、Javaではけっこう使われているちゃんとした技術だよ。
DIコンテナでは標準的な技術。

261 ：デフォルトの名無しさん：2009/07/23(木) 02:44:03

実現方法は別としてLISPとかでも普通にやってることだしね。 > AOP
昔ながらのやり方に新しい名前が付いただけで「バズワード(笑)」になっちゃうわけもなく。

262 ：デフォルトの名無しさん：2009/07/23(木) 02:57:50

NokogiriがWindows-31Jエンコーディングをサポートしていない気がする。
正確にはNokogiriが使っているlibxml2が呼んでいるiconvかもしれないけど。

>irb -Ks -rrubygems -rnokogiri
#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>"

#エンコーディング指定なしでHTMLパース。当然失敗。
irb(main):002:0> Nokogiri::HTML.parse(s)
encoding error : output conversion failed due to conv error, bytes 0x82 0x50 0xC
2 0x87
I/O error : encoder error
=>

#Windows-31JエンコーディングでHTMLパース。失敗。
irb(main):003:0> Nokogiri::HTML.parse(s,nil,'Windows-31J')
encoding error : output conversion failed due to conv error, bytes 0x82 0x50 0xC
2 0x87
I/O error : encoder error
=>

263 ：デフォルトの名無しさん：2009/07/23(木) 03:00:30

#CP932エンコーディングでHTMLパース。成功。
irb(main):004:0> Nokogiri::HTML.parse(s,nil,'CP932')
=> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.
org/TR/REC-html40/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=CP932">
<title>1１①1１①</title>
</head>
<body></body>
</html>

#Shift_JISエンコーディングでHTMLパース。Shift_JISの範囲内のところまで中途半端にパース。想定通り。
irb(main):005:0> Nokogiri::HTML.parse(s,nil,'Shift_JIS')
=> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.
org/TR/REC-html40/loose.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
<title>1１</title>
</head></html>

ちなみに環境はこんな感じ。現在入手できる最新のActiveScriptRubyとNokogiri。
>ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [i386-mswin32]
>gem list nokogiri
I:\home\a_i\script>gem list nokogiri

*** LOCAL GEMS ***

nokogiri (1.3.2)

264 ：デフォルトの名無しさん：2009/07/23(木) 03:18:51

さくっとパッチ書いて配布しないの？
wktk

265 ：デフォルトの名無しさん：2009/07/23(木) 03:36:14

Nokogiri::HTML.parse(s,nil,'Windows-31J')
のときに実際には
Nokogiri::HTML.parse(s,nil,'CP932')
とやるようなのはすぐに出来るだろうけど、
変換結果とかエンコーディング情報はCP932になっちゃうから、

パース時に明示的に指定したエンコーディングと、
パース後に取得できるエンコーディングの内容が同一と仮定してるような
プログラム、具体的にはMechanizeとかが困ったことになる悪寒。

266 ：デフォルトの名無しさん：2009/07/23(木) 06:46:26

個々人の環境でインストールされている iconv が実際にどんだけの範囲をサポートしているかは
iconv 利用ライブラリ側ではもうどうしようもない
「自動でやりたいなら WINDOWS-31J をサポートしてる iconv を自分でインストールしろ」で終了
そんなこと言ったらそもそも x-sjis なんかも読めないわけだし

ちなみに手元の Ubuntu では普通に動作する
irb> s = Iconv.conv('WINDOWS-31J', 'UTF-8', "<html><HEAD><TITLE>1１①1１①</TITLE></HEAD><body></body></html)"
irb> Nokogiri::HTML.parse(s,nil,'Windows-31J')
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-31J">
<title>1?P?@1?P?@</title>
</head>
<body></body>
</html>

267 ：デフォルトの名無しさん：2009/07/23(木) 07:39:51

1.8もiconvも捨てて、1.9/transcode使おうぜ！

268 ：デフォルトの名無しさん：2009/07/23(木) 07:41:36

Ruby って不幸なんですね
日本語得意っていうのが嘘に聞こえる

269 ：デフォルトの名無しさん：2009/07/23(木) 07:50:24

iconv と小文字で書いてるのが読めんようだが、
まあ Encode.pm を再発明しなかったのが罪だというならそれはそれで

270 ：デフォルトの名無しさん：2009/07/23(木) 07:51:48

Rubyが日本語が得意だと言ってるユーザーはぶっちゃけいないと思う

271 ：デフォルトの名無しさん：2009/07/23(木) 07:57:22

比較スレとかで「日本語処理が得意」とか書かれてるのは時々見る
つまりRubyを使ってない人にはそう見えるんだろう

272 ：デフォルトの名無しさん：2009/07/23(木) 08:26:58

つまりRubyを使ってない人が
比較スレとかで「日本語処理が得意」とか書いてるのか

273 ：デフォルトの名無しさん：2009/07/23(木) 08:35:47

・文字列処理は得意
・日本語の取り扱いもできる
　→日本語処理も得意なはず！

こういう図式が成立してそうなイメージが
嘘じゃあないが、他のスクリプト系言語と比べて
とりたてて得意かと言われると微妙な所

274 ：デフォルトの名無しさん：2009/07/23(木) 08:46:08

日本語版Windowsの標準エンコーディングがUTF-8になれば
UTF-8以外を使う人間はごく短期間で絶滅寸前になるような気もするので、
これから本当にそれほどまでの対応が必要なのかという疑問がいつもある。

275 ：デフォルトの名無しさん：2009/07/23(木) 09:05:08

そもそも「日本語処理が得意」って言い方からして曖昧すぎる
どうすれば得意だと言えるんだ？

たとえばruby1.8のように、あまり難しいこと考えずにエンコーディングを扱えるのが良いのか？
ruby1.9のように、各文字列のエンコーディングを厳密に扱えるのが良いのか？
それとも他言語のように、すべてUTF-8で統一されてるのが良いのか？

やっぱりRuby使ったことない人が書いてるだけなんじゃないか、と疑いたくもなる

276 ：デフォルトの名無しさん：2009/07/23(木) 09:05:44

朝から活発だな

277 ：デフォルトの名無しさん：2009/07/23(木) 09:16:21

>日本語版Windowsの標準エンコーディングがUTF-8になれば

I agree, but there are many SJIS records on HDD.

278 ：デフォルトの名無しさん：2009/07/23(木) 09:18:13

>>275
各文字列のエンコーディングを厳密に扱えるのが良い

279 ：デフォルトの名無しさん：2009/07/23(木) 11:11:31

ShiftJIS というか CP932（相当）で作ったファイルがもれなく UTF-8（と共通で決まったもの）で表現できるなら
そりゃ移行はもうあっさり済むと思うんだが
実際はそうではないわけで

280 ：デフォルトの名無しさん：2009/07/23(木) 11:14:23

Summer holidays has come.

281 ：デフォルトの名無しさん：2009/07/23(木) 11:47:25

>>279
漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。
大体、それこそMSお得意の「コードページの切り替え（バグ込み込み）」で
対応できるんじゃねーのとか。

282 ：デフォルトの名無しさん：2009/07/23(木) 12:04:12

ファイルそのものにファイルのエンコーディング情報を含めなかったのが間違いの元
Macと違って

283 ：デフォルトの名無しさん：2009/07/23(木) 12:38:14

>>281
>漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。

この手の問題は、数が少ないからといって無視できるものではない。
というより、データ変換については間違いがあってはならないのが前提であり、
すこしでも間違いがあれば大きな問題。
１文字でもうまくいかないのがあれば、移行しない人が大勢いても不思議ではない。

284 ：デフォルトの名無しさん：2009/07/23(木) 13:13:38

cp932はもれなくユニコードで表現できるでしょ？
じゃなきゃW系APIとかどうすんのかと

285 ：デフォルトの名無しさん：2009/07/23(木) 13:16:48

マクはいろいろ問題が。

286 ：デフォルトの名無しさん：2009/07/23(木) 13:31:41

UTF-8だと日本語が1文字3バイトになるから嫌だと言って譲らない人が稀にいるけど、
そういう人に限って、コンピューターが高速になってるからインタープリタ言語でも問題ないとか言うんだよね。

287 ：デフォルトの名無しさん：2009/07/23(木) 13:34:12

Perlがまだjcode.pl全盛期でUnicodeなんか誰も使ってなかった頃、
Rubyは既に日本語(EUC-JP, SJIS)に対応していた。

というだけで今となっては別に日本語処理がとりわけ得意なわけではない。
1.9はノウハウがたまってくれば良いかも。

288 ：262：2009/07/23(木) 13:53:35

>>266
>「自動でやりたいなら WINDOWS-31J をサポートしてる iconv を自分でインストールしろ」で終了
>ちなみに手元の Ubuntu では普通に動作する
ああ、やっぱりそんなところですよね。

で、今回問題となってるiconvですが、
Nokogiriの公式のWindows向けgemパッケージに同梱されてるiconv.dllなんですよね。
つまりWindowsでgem install nokogiriしたときに標準で使われるものがこの状態という。

一番丸く収まる対処としては公式にお願いして同梱するiconvを変えてもらうとかそんなところでしょうか。
さすがにIANAに登録されてる分ぐらいはエイリアスが効かないとHTML/XMLの処理という
趣旨から困るはずなので。

現状、Mechanize経由で使ったりする分には、
コンテンツ取得後にレスポンスボディをNKFでUTF-8に変換して差し替えて
レスポンスのコンテントタイプのキャラクターセットもUTF-8に差し替えてしまえば
実用上はほとんど問題なさそうです。

もちろんWindows-31J->UTF8->Windows-31Jと変換したときに
変換前と後とでバイナリが一致しなくて困るケースとか、
サーバから取得した時点でのエンコーディングを意識しておく必要があるケースとかは
マズいんですが、まあそう多くはないだろう、という。

289 ：デフォルトの名無しさん：2009/07/23(木) 14:13:03

文字コード変換はJavaとかPerlとかがまあ道を切り開いてはくれてるけど
Javaの文字コード周りの大変さとか、
Perlが4から5へ上がったときに配布サイズが膨れ上がった原因の大半が
文字コード変換テーブルのせいだった、とか考えると
Rubyでやるべきかどうか、ってのは悩ましいな。
特にRubyはCSIで頑張るつもりなわけで、より大変な道だし。

290 ：デフォルトの名無しさん：2009/07/23(木) 14:23:46

>>284
もういちど>>279を読もうぜ

>>279
>ShiftJIS というか CP932（相当）で作ったファイルがもれなく UTF-8（と共通で決まったもの）で表現できるなら
>そりゃ移行はもうあっさり済むと思うんだが
>実際はそうではないわけで

291 ：デフォルトの名無しさん：2009/07/23(木) 14:25:39

>>288
Mechanize::Page#encoding= 使え
引数を Nokogiri::HTML.parse の第3引数に渡して page の HTML を再パースしてくれる

　agent.get(windows_31j_uri)
　agent.page.encoding = 'CP932'

今の iconv の CP932 は WINDOWS-31J と全く同じだから
（つまり、WINDOWS-31J 以前の CP932 には非対応）、
WINDOWS-31J の代わりに CP932 を渡しても構わない

あと、Ubuntu にインストールされている iconv は非公式パッチが入ったものだ
オフィシャルな iconv は
ttp://www.gnu.org/software/libiconv/
> Japanese
> EUC-JP, SHIFT_JIS, CP932, ISO-2022-JP, ISO-2022-JP-2, ISO-2022-JP-1
> EUC-JISX0213, Shift_JISX0213, ISO-2022-JP-3 (--enable-extra-encodings 有効時)
これ以外をサポートしないし、サポートする義理もない

292 ：デフォルトの名無しさん：2009/07/23(木) 15:08:47

>>291
事前にコードが仮定できればそれでOKというかベストですね。

ちなみに当初ハマっていたシナリオだと

とあるページをパースすると途中で内容が途切れたようなパース結果が帰ってくる
->元データを確認したらWindows-31J相当の内容のページに設定されたmetaタグの内容がShift_JIS
->encodingにWindows-31J指定->内部的には未知のエンコーディングでエラー。なかったことに。
->再パースされるもmetaタグのエンコーディングでパース
->外観的には何度encodingを再設定してもencodingがShift_JISのまま
->大☆混☆乱

とかまあそんな感じでしたw

293 ：デフォルトの名無しさん：2009/07/23(木) 15:44:28

>>290
具体的にどの文字がUTF-8で表現できないんだ?

294 ：デフォルトの名無しさん：2009/07/23(木) 16:09:56

CP932→UTF-8自体は、記号の意味上はともかく文字の見掛けの形だけは大丈夫だったはず
逆は不可だが

295 ：デフォルトの名無しさん：2009/07/23(木) 16:14:24

>>293
その辺の話はCP932については
ttp://ja.wikipedia.org/wiki/Microsoftコードページ932
がまとまってるんじゃないかな

296 ：デフォルトの名無しさん：2009/07/23(木) 18:19:41

UNICODEってあほなの？
文字コード統一するどころか
種類増やしてさらに面倒にしただけじゃないの？

297 ：デフォルトの名無しさん：2009/07/23(木) 18:25:18

iso-8859-*は統一されたんだろ

298 ：デフォルトの名無しさん：2009/07/23(木) 18:56:04

日本国内の文字コードも統一できない民族よりはマシ

299 ：デフォルトの名無しさん：2009/07/23(木) 19:01:14

>>296
JIS EUC-JP Shift_JISを使い分け続けるよりは遙かに分別があるよ

300 ：デフォルトの名無しさん：2009/07/23(木) 19:09:45

100年後も使い分けしつづけてるんじゃないかなぁ？w

301 ：デフォルトの名無しさん：2009/07/23(木) 19:13:33

毛沢東の文化大破壊みたいな歴史的事件でも起こさない限り統一は無理だろ

302 ：デフォルトの名無しさん：2009/07/23(木) 19:24:07

>>291
ubuntuのiconvはglibcのiconv

303 ：デフォルトの名無しさん：2009/07/23(木) 19:25:18

>>301
必要に応じてうだうだ追加してきただけの既存規格が
もうそんなに文化的なものになってるのかｗ

って、もとから超人工的で場当たり的なものなんだからそれはねーよ
、とマジレスｽﾏｿ

304 ：デフォルトの名無しさん：2009/07/23(木) 19:59:21

文化で人工的でなくて場当たり的でないものはあるのか
それこそ非文化だろ

305 ：デフォルトの名無しさん：2009/07/23(木) 20:23:45

Perl、インターネット、日本語漢字コードあたりは、「とりあえず作ってみた」が
実用に供されていろいろ問題が尾を引いている事物の代表だな。

306 ：デフォルトの名無しさん：2009/07/23(木) 20:25:39

Cもしかり
Javaもしかり
GAEもしかり

307 ：デフォルトの名無しさん：2009/07/23(木) 20:27:02

Rails もしかり www

308 ：デフォルトの名無しさん：2009/07/23(木) 20:28:10

>>305
>「とりあえず作ってみた」

Rubyもその代表なんだが

309 ：デフォルトの名無しさん：2009/07/23(木) 20:34:18

長く大勢に使われる人工物で統一取れているものなんていくつあるんだか。

310 ：デフォルトの名無しさん：2009/07/23(木) 20:40:12

車のエンジンレーキハンドルを変えようかって話は出たり出なかったり

311 ：デフォルトの名無しさん：2009/07/23(木) 20:49:00

> Ruby って不幸なんですね
> 日本語得意っていうのが嘘に聞こえる
> Rubyが日本語が得意だと言ってるユーザーはぶっちゃけいないと思う
> 比較スレとかで「日本語処理が得意」とか書かれてるのは時々見る

基本的に自然言語は難しい、「得意」というよりは、「比較的マシ」と言い換えた方が実情に近い。

> こういう図式が成立してそうなイメージが
> 嘘じゃあないが、他のスクリプト系言語と比べて
> とりたてて得意かと言われると微妙な所

確かにPerl5.8以前においては、Rubyは-Kがあるだけかなりマシだった。

> まあ Encode.pm を再発明しなかったのが罪だというならそれはそれで

Ruby 1.9のEncoding/transcodeはソレですよ。
まぁ、再発明すれば解決ってほど文字コードの世界は甘くない。
Rubyより下のレイヤーに依存しないだけマシって話ですな。

> 日本語版Windowsの標準エンコーディングがUTF-8になれば

Windowsは互換性にかなり気を使うからどうだろうねぇ。
デフォルトがUTF-8になるまでまだまだかかると思うよ。

> UTF-8以外を使う人間はごく短期間で絶滅寸前になるような気もするので、
> これから本当にそれほどまでの対応が必要なのかという疑問がいつもある。

で、その時にはデータ移行しないといけないんだ。
また、すでにあるWebデータは多分そのままだよ

312 ：デフォルトの名無しさん：2009/07/23(木) 20:49:53

> そもそも「日本語処理が得意」って言い方からして曖昧すぎる
> どうすれば得意だと言えるんだ？

とりあえず8bitの文字列が通れば「得意」って言っていいんじゃないの。

> たとえばruby1.8のように、あまり難しいこと考えずにエンコーディングを扱えるのが良いのか？

Ruby 1.8はエンコーディングは扱っていない、扱っているのはバイト列です。
エンコーディングを扱っているのは、Rubyでなくもっと上のレイヤーだね、jcode.rbとかはのぞいて。

> ruby1.9のように、各文字列のエンコーディングを厳密に扱えるのが良いのか？

Ruby 1.9みたいなCSIプログラミング環境ってのは他に例がきわめて少ないので、是非お試しください。

> それとも他言語のように、すべてUTF-8で統一されてるのが良いのか？

これは結構あるよね、Rubyも将来的にはUnicodeに統一する方向になっていくのかもしれん。
まぁ、少なくとも1.9ではCSIのまま突っ走るはずなのでご安心ください。

> やっぱりRuby使ったことない人が書いてるだけなんじゃないか、と疑いたくもなる

Rubyを使ったことがないか、Rubyよりはるかに悲惨な環境での経験が長いかの二択だろうね。

313 ：デフォルトの名無しさん：2009/07/23(木) 20:51:08

> ShiftJIS というか CP932（相当）で作ったファイルがもれなく UTF-8（と共通で決まったもの）で表現できるなら
> そりゃ移行はもうあっさり済むと思うんだが
> 実際はそうではないわけで

>>281 一応理論上はもれなく表現可能だよ、最近はテーブルも統一されてきたし。
ただ、とりあえずWindowsがロケールをUTF-8に移行しないうちは無理でしょうね。

> 漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。
> 大体、それこそMSお得意の「コードページの切り替え（バグ込み込み）」で
> 対応できるんじゃねーのとか。

>>283 1文字でもあれば普通は移行不可能だと考えるべきでしょう。
まぁ、一応一度片道切符で移行するだけなら、先述の通り大丈夫。

> ファイルそのものにファイルのエンコーディング情報を含めなかったのが間違いの元
> Macと違って

Joelが言ってたけど、plain textはplainじゃないんだよね、外部からエンコーディングを指定しないと。
まぁ、外部からのエンコーディング指定がまたそれはそれで腐ってたりするんだけど。

314 ：デフォルトの名無しさん：2009/07/23(木) 20:54:41

> マクはいろいろ問題が。
Macは「ごかんせい？なにそれ？おいしいの？」だからなぁ、MacJapanese仕様変わりすぎ。

> UTF-8だと日本語が1文字3バイトになるから嫌だと言って譲らない人が稀にいるけど、

もうそんな時代錯誤な人いないよね？オレオレUTFとかやめてよ、ほんとに。

> で、今回問題となってるiconvですが、
> Nokogiriの公式のWindows向けgemパッケージに同梱されてるiconv.dllなんですよね。
> つまりWindowsでgem install nokogiriしたときに標準で使われるものがこの状態という。
> > 一番丸く収まる対処としては公式にお願いして同梱するiconvを変えてもらうとかそんなところでしょうか。

>>288 ライブラリとしてマルチプラットフォームで使えるiconvは今のところGNU libiconvしかないと思う。
しかし、GNU libiconvはメンテナがDQNなせいで、MS系エンコーディングを整理するパッチが取り込まれていない。
ので、パッケージやバイナリの配布者が別にパッチをあてる必要がある。
例えばFreeBSDのportsはlibiconvが入っているのだが、これには森山さんのパッチが当てられてる。
ので、同様なことをしてもらえばいいんだけど……。

315 ：デフォルトの名無しさん：2009/07/23(木) 21:04:24

>>312
CSIは仕様？それとも実装依存？

316 ：デフォルトの名無しさん：2009/07/23(木) 21:26:15

>>314
DQNというより問題点が理解されてないんでは?

317 ：デフォルトの名無しさん：2009/07/23(木) 21:50:32

> 現状、Mechanize経由で使ったりする分には、
> コンテンツ取得後にレスポンスボディをNKFでUTF-8に変換して差し替えて

それよりはCP932に差し替えた方がいいのでは

> >>289
> 文字コード変換はJavaとかPerlとかがまあ道を切り開いてはくれてるけど
> Javaの文字コード周りの大変さとか、
> Perlが4から5へ上がったときに配布サイズが膨れ上がった原因の大半が
> 文字コード変換テーブルのせいだった、とか考えると
> Rubyでやるべきかどうか、ってのは悩ましいな。

彼らは大変だったのでしょうねぇ、先人の苦労には頭が下がります。。
まぁ、彼らが残したShift_JIS変換テーブルみたいなゴミに苦労もしてたりするんですけど。

> 特にRubyはCSIで頑張るつもりなわけで、より大変な道だし。

まぁ、CSIだと変換表を用意しないって技もあったりするんですよ。

> 今の iconv の CP932 は WINDOWS-31J と全く同じだから

実装依存です。

> あと、Ubuntu にインストールされている iconv は非公式パッチが入ったものだ

Ubuntu は glibc iconvで、libiconvとは別物ですね。
glibc iconvには森山さんのパッチが取り込まれています。

> CP932→UTF-8自体は、記号の意味上はともかく文字の見掛けの形だけは大丈夫だったはず
> 逆は不可だが

意味的にも大丈夫ですよ、問題が出るのはShift_JISと混ぜた時の話。

318 ：デフォルトの名無しさん：2009/07/23(木) 21:54:49

> UNICODEってあほなの？
> 文字コード統一するどころか
> 種類増やしてさらに面倒にしただけじゃないの？

UnicodeがなかったらJIS X 0213対応とかで確実に大惨事になってた。
UnicodeのおかげでShift_JISX0213とかを無視することが出来た、すばらしい。

> 日本国内の文字コードも統一できない民族よりはマシ
別にSJIS<->EUC<->JISは計算の問題だからたいしたことはないのさ。

> 毛沢東の文化大破壊みたいな歴史的事件でも起こさない限り統一は無理だろ

まぁ、順次UTF-8に移っていくとは思うよ、やっぱりよくできたエンコーディングだし。
バイト列として扱う時の事を考えてよく設計されてるよ。

> >>301
> 必要に応じてうだうだ追加してきただけの既存規格が
> もうそんなに文化的なものになってるのかｗ
>>304 と同意見で、場当たり的拡張の積み重ねこそが、取り決めを文化にするんだと思いますよ。

> >> 315 CSIは仕様？それとも実装依存？

Ruby 1.9はCSIが仕様なので、MacRubyとかはCSIなはずです、Rubyレイヤでは。

> >>316
> >314
> DQNというより問題点が理解されてないんでは?
http://www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/bbs.cgi?c=gr&n=416
とかをはじめとして、なんどもコンタクトは取っているようなので、
たぶんあまりのカオスっぷりにびびってデジュールの気持ちよい世界に逃げたんだと思っています。
Safari/Webkitとかもそう言う傾向があるので、海外だと一定存在するかな。
まぁ、勘違い・偏見である可能性を否定はしませんけど。

319 ：デフォルトの名無しさん：2009/07/24(金) 01:02:58

本家に取り込んでください
http://www.moongift.jp/2009/07/ruby-php/#more-16888

320 ：デフォルトの名無しさん：2009/07/24(金) 01:30:24

>>319
勘弁してくれ。

321 ：デフォルトの名無しさん：2009/07/24(金) 01:34:01

LTネタだって知らないと本気の拡張に見えそうだな。

322 ：デフォルトの名無しさん：2009/07/24(金) 08:43:00

>>317
>> 現状、Mechanize経由で使ったりする分には、
>> コンテンツ取得後にレスポンスボディをNKFでUTF-8に変換して差し替えて
>それよりはCP932に差し替えた方がいいのでは
コンテンツのcharsetが予測できない場合だとどれかに決め打つことになるわけですが、
その場合だと文字集合的に一番広いUnicodeにせざるをえないかと。
この場合でもNKFで対応できないコードが入ってくればアウトなのでまあ、
実用上そうそう困らなくてそれなりに楽、って程度の話ではありますが。

>>318
>まぁ、順次UTF-8に移っていくとは思うよ、やっぱりよくできたエンコーディングだし。
>バイト列として扱う時の事を考えてよく設計されてるよ。
ですね。
ASCIIがそのまま通って、かつファイルシステムクリーンというのは素晴らしい。

323 ：デフォルトの名無しさん：2009/07/24(金) 08:53:01

ISO-2022-JP-* みたいなイビツなシロモノがスタンダードにならなくて本当に良かったわ
「Unicodeでは全ての文字を含められない」ってのが理由だったがぶっちゃけどうでもいいし

324 ：デフォルトの名無しさん：2009/07/24(金) 09:09:25

新しい文字は放っておいても生まれる。絵文字とか。
というわけで、 UTF-8 系列をとりあえずの基盤として受け入れたのはたぶん結果的にはマシ。

325 ：デフォルトの名無しさん：2009/07/24(金) 09:11:43

余裕をもってUCS4にしようぜ

326 ：デフォルトの名無しさん：2009/07/24(金) 09:28:58

>>324
その割にはサロゲート対応だの、4バイトまでだの、
なかなか中途半端な現状だけどな
UTF-16ってのが諸悪の根元か？

327 ：デフォルトの名無しさん：2009/07/24(金) 09:39:34

UTF-8 は尖兵
ユニコードとやらも意外と悪くないではないかとか思わせるために敢えて本筋を剥いだ草

328 ：デフォルトの名無しさん：2009/07/24(金) 09:48:30

I'm perfect soldier.

329 ：デフォルトの名無しさん：2009/07/24(金) 09:49:35

草とか言うな(w

気がついたら UTF-8 ファイルと UTF-8 アプリケーションばっかで
他のエンコーディング系列に移行できなとかそんなのか

330 ：デフォルトの名無しさん：2009/07/24(金) 09:59:43

最強の尖兵乙

331 ：デフォルトの名無しさん：2009/07/24(金) 11:03:52

>>321
最初からRejectKaigiを狙ってたんじゃないのか?

332 ：デフォルトの名無しさん：2009/07/24(金) 11:45:19

あああ、LTじゃなくてRejectKaigiか。

333 ：デフォルトの名無しさん：2009/07/25(土) 01:02:24

rubyってjisちゃんと扱えないのか。苦労するはずだわ。
ruby捨ててjavaでがんばる。

334 ：デフォルトの名無しさん：2009/07/25(土) 01:06:25

> rubyってjisちゃんと扱えないのか。苦労するはずだわ。
何の話をしてるの？

335 ：デフォルトの名無しさん：2009/07/25(土) 01:10:08

> 余裕をもってUCS4にしようぜ
UCS-4も最新のISOでは0x10FFFFまでしか文字を定義しないことになったよ。

> その割にはサロゲート対応だの、4バイトまでだの、なかなか中途半端な現状だけどな
サロゲートペアはUTF-16の話で、UTF-8にはあまり。4バイトまでなのは困らないでしょ。

> UTF-16ってのが諸悪の根元か？
本質的にはUCS-2が根源かな。

> UTF-8 は尖兵
UTF-8が最終形じゃないかな、UCS-2やUTF-16の方がむしろpreview。

336 ：デフォルトの名無しさん：2009/07/25(土) 01:11:42

一文字64bitの新文字コード作ろうぜ

337 ：デフォルトの名無しさん：2009/07/25(土) 01:24:59

>>335
そこが今ひとつわからんのだが、31bitあったのを21bit？にしたのは、
なにか技術的な要請があったの？
それとも、先行したUCS2に引きずられただけ？

256*256*17面（だっけ）にしたのは、どういうことなんだろう。

338 ：デフォルトの名無しさん：2009/07/25(土) 03:13:11

>>337
まず、31bitだったのはsigned int32ね。
0x10FFFFまでなのは、UTF-16の収録限界が由来で、
BMPの0xFFFF+サロゲートペアの(0xDC00-0xD800)*(0xE000-0xDC00)だから

339 ：デフォルトの名無しさん：2009/07/25(土) 06:35:23

そもそもUnicode自体がクソだろ
文字鏡をつかっていればあるいわ

340 ：デフォルトの名無しさん：2009/07/25(土) 07:24:13

現実的にUnicodeより良い物があるの？

341 ：デフォルトの名無しさん：2009/07/25(土) 09:45:27

Unicode一本化されたとこから漸次さらに優れたものに移行すればいいじゃん
カオス状態がUnicodeのおかげでずいぶんましになってる所なのに

342 ：デフォルトの名無しさん：2009/07/25(土) 11:29:26

Rubyスレなのに気付いたらUnicodeの話になってた!

343 ：デフォルトの名無しさん：2009/07/25(土) 11:30:10

文字コードの話はなぜか妙に食いつきがいい

344 ：デフォルトの名無しさん：2009/07/25(土) 11:35:23

開発コアメンバが語るRubyの今とこれから（前編）
http://www.atmarkit.co.jp/news/200907/24/ruby.html

そろそろ1.8系から1.9に移るころなのかな？

345 ：デフォルトの名無しさん：2009/07/25(土) 12:35:10

>>341
Unicodeがある意味全てを終わらせてしまったので、
優れたものが出てくる余地はない。
Unicodeが優れたものなんじゃなくて、悪貨は良貨を駆逐するという意味で。

346 ：デフォルトの名無しさん：2009/07/25(土) 12:46:51

日本の3つの文字コードへの対応ライブラリパッチのファイルサイズ見れば、色々間違いだと思えるようになるよ

>>344
なんでこう、ちょっとカッコいいポーズしてください写真なん？
や、写真使うのは取材側の人だから要望聞いたほうがいいんだけどさ

Ruby1.9 に移行するのは絶対に間違いない
問題は、そのためのライブラリサポートの手間をいつ誰が取るかだと思う

外国の人はいろんな意味で慎重な移行をやりたがらないと思うんで、
それこそマルチバイトユーザーで最大Rubyコミュニティである日本人の出番なのではないかと

英語のライブラリ作者向けガイド書いた人がどっかにいたが、ああいうの頑張るべきかもしれない

347 ：デフォルトの名無しさん：2009/07/25(土) 12:50:53

弾子飼かと思った

348 ：デフォルトの名無しさん：2009/07/25(土) 12:55:37

とりあえず rubyrb1.9 test/ で Ruby1.9 対応完了とかほざく外人作者さんの調教から

古い rubygem でしか動かないライブラリが捨てられていくのと同じように、
Ruby 1.9 で実際上動作しないライブラリが捨てられていくようになればいいんだけど

349 ：デフォルトの名無しさん：2009/07/25(土) 13:11:14

Railsが1.9でまともに動けば移行が進むんじゃね。

350 ：デフォルトの名無しさん：2009/07/25(土) 14:20:13

つまり asakusa.rb 期待 age?

351 ：デフォルトの名無しさん：2009/07/25(土) 19:38:39

>>344
記事内容とはまったく関係ないし、たぶん写真写りのせいだと思うんだが
2枚目の写真のYugui氏が怖い

352 ：デフォルトの名無しさん：2009/07/25(土) 19:39:58

UTFが、8859と互換なのが大きいからなあ。日本人が使えないって騒いだって、欧米圏は、もう他に移行はしないだろう。

353 ：デフォルトの名無しさん：2009/07/25(土) 19:48:08

>>344
率直に言って恥ずかしいな
写真が気になって記事が頭に入らない

354 ：デフォルトの名無しさん：2009/07/25(土) 19:49:35

>>352
使えるのに使いたくないって騒いでるだけじゃないかと

355 ：デフォルトの名無しさん：2009/07/25(土) 19:54:58

>>351
全てがマイナスに働いている、ある意味レア写真
著者近影に使ったら書籍自体が山積みでお祓いに出されるレベル

もうちょっちいいのなかったんかね

356 ：デフォルトの名無しさん：2009/07/25(土) 20:00:03

>>352
互換じゃないお
互換なのは ISO-8859-1 の部分だけだお
それ以外の 2 から 16 くらいまでの文字は、文字は入ってるけど互換性ないお

357 ：デフォルトの名無しさん：2009/07/25(土) 20:10:41

キモイキモイキモイキモイ
キモイキモイキモイキモイ
キモイキモイキモイキモイ
キモイキモイキモイキモイ

358 ：デフォルトの名無しさん：2009/07/25(土) 20:46:12

>>339
文字鏡はライセンスが問題になって以来、もうないと思うけどな

359 ：デフォルトの名無しさん：2009/07/25(土) 20:47:32

>>351
目が白目むいてるように見えるのが大きいんだろうな

360 ：デフォルトの名無しさん：2009/07/25(土) 22:26:04

ホントにキモイな。

Ruby関係って、他にもキモイやついなかったか?

361 ：デフォルトの名無しさん：2009/07/25(土) 22:32:55

1.9っていうと開発版だから～って思って2.0をずっと待ってた。
そんなに自信もって進められるなら2.0リリースしてくれよ。

362 ：デフォルトの名無しさん：2009/07/25(土) 22:42:04

インタビュー経由で疑問に思ったんだが、Rubiniusって結局何がどう嬉しくなるんだ？
・コードをそのままRubyオブジェクトにできる
・BSDライセンスになる
ことぐらい？

そもそも、CRubyの上で動くRubiniusが、CRubyより速くなるというのがよく理解できない
詳しい人がいればぜひ教えてほしい

363 ：デフォルトの名無しさん：2009/07/25(土) 22:45:51

まだ>>361みたなこと言ってるやつがいるのか

364 ：デフォルトの名無しさん：2009/07/25(土) 22:46:13

1.9使ってたけどRailsを使う必要があったんで1.8に戻した。
1.8でも十分速いし、対応ライブラリも豊富だからこれでいいよ

365 ：デフォルトの名無しさん：2009/07/25(土) 22:49:18

みんな！民主党が大変な事になってるよ。
http://www.nicovideo.jp/watch/sm7737318

366 ：デフォルトの名無しさん：2009/07/25(土) 22:49:24

>>360
> 他にもキモイやついなかったか?
好きで使ってる奴でキモくない人間を一人も見たこと無いよ。

367 ：デフォルトの名無しさん：2009/07/25(土) 22:49:36

一方おれは1.9でRailsを使っている。
特に大きな問題はなく今のところすべて回避できている。
回避できない問題もあるんだろうが。

368 ：デフォルトの名無しさん：2009/07/25(土) 22:52:45

>>362
対象の言語でVMを実装できるというところが「きれい」

369 ：デフォルトの名無しさん：2009/07/25(土) 23:50:54

pythonってVMだったか？
Ruby VM より早いPythonってどうなんだろうね

370 ：デフォルトの名無しさん：2009/07/25(土) 23:51:03

心の底から>>361と同意見

MatzはなぜRite=2.0にこだわるんだ
今の1.9.1を2.0にして、Riteを3.0にしたらいいのに

371 ：デフォルトの名無しさん：2009/07/25(土) 23:51:35

【科学】道路に軍手が落ちているワケ、名城大研究チームが突き止める[09/07/24]

http://namidame.2ch.net/test/read.cgi/hidari/1225537555/

372 ：デフォルトの名無しさん：2009/07/25(土) 23:57:09

>>362
アルゴリズムによってはCで書かれたHaskellがCよりも速いのと一緒

373 ：デフォルトの名無しさん：2009/07/26(日) 04:16:25

2.0 への思い入れ云々を除いても、バージョン1をバージョン2に上げるほどの何某があるとは思えん
1.9.1 の次くらいを 2.0 にするならまあアリかなと思う

1.9.1p0 の存在が鬱陶しいと思ってる人は少なくないはずだよ

374 ：デフォルトの名無しさん：2009/07/26(日) 04:27:31

1.9.1 は本体オンリーはともかく第三者ライブラリ全体を含んだ便利度はまだまだだなー、と感じるわけだが、
これが 2.0 だった場合は「バージョン 2.0 とか言ってる割には全然…」だの
「2.0 はアレなので 2.0.4 以降インストールしてください」だのいうことになったと思う

今現在我々が 1.9.1 の使い勝手に抱いている感想は、
それのバージョンが 2.0 だったからといっていい方向に作用したと思われるものではない、はず

375 ：デフォルトの名無しさん：2009/07/26(日) 11:15:43

ttp://d.hatena.ne.jp/mrkn/20090717/rubykaigi2009_trap
ヒドスwww

376 ：デフォルトの名無しさん：2009/07/26(日) 16:42:35

ささぴーひっどーぉい。（か☆わ★い☆い★女☆子★高☆生　より

377 ：デフォルトの名無しさん：2009/07/26(日) 17:06:50

うわぁ

378 ：デフォルトの名無しさん：2009/07/26(日) 19:52:21

おいtrunkのrakeやrdocやrubygemsは最新版にアップデートしないのか

379 ：デフォルトの名無しさん：2009/07/26(日) 20:11:05

ruby-coreでいえ

380 ：デフォルトの名無しさん：2009/07/26(日) 21:03:56

アップデートしてくれる度にtest-allのエラー数が激増するんで困ってる

381 ：デフォルトの名無しさん：2009/07/27(月) 11:34:32

> Google App EngineではJRails on Rubyも動いてます。
> もうJVMでいいじゃんっていうことになる危機感は？

ここはまつもとさんじゃなく、
ささださんの回答が見たかった。

382 ：デフォルトの名無しさん：2009/07/27(月) 13:42:39

bigtableは独特だからなぁ

383 ：デフォルトの名無しさん：2009/07/27(月) 14:31:58

ここに書けばささださんの回答は得られる

384 ：デフォルトの名無しさん：2009/07/27(月) 14:59:14

Rails で web アプリケーションをやろうとしていて、
1.9 系はまだ使いたくないという場合は、1.8.7 を選んでおけばいいのでしょうか？

385 ：デフォルトの名無しさん：2009/07/27(月) 15:02:50

あい

「一般ユーザー」でRuby1.9を現在使うメリットとデメリットを均すとマイナスになります
エラーの意味も原因もさっぱりわからん直せと言われてもさっぱり、な人はしばらく 1.8.7 で待機しましょう

386 ：デフォルトの名無しさん：2009/07/27(月) 15:16:21

自力で改修くらいできるぜﾋｬｯﾊｰという人はガンガン 1.9.1 を使って欲しいところ
汎用性があったらライブラリ作者に連絡でもしてくれ

387 ：デフォルトの名無しさん：2009/07/27(月) 15:19:38

そんな人が何人いるんだよ…

388 ：デフォルトの名無しさん：2009/07/27(月) 15:47:28

改修くらいはできるけど
あえて1.9.1以降を、自分から積極的に使う意欲はわかない

389 ：デフォルトの名無しさん：2009/07/27(月) 15:48:51

github になったら commit する人とか少し出るかも

390 ：デフォルトの名無しさん：2009/07/27(月) 17:22:17

ちょっとだけ違う野良フォーク祭りになるだけのような気がしなくもないが、
ブログとかに差分がちょこっと書かれてるだけとかいうのよりは遥かにマシか

391 ：デフォルトの名無しさん：2009/07/27(月) 18:06:17

なにをどうすれば pull request に足るものなのかよくわかんないんだよね
だったら自分専用でいっかーみたいな

392 ：デフォルトの名無しさん：2009/07/27(月) 18:08:36

そういう混沌状態を意図してるのでないの？
思いっきりforkやcommitの敷居を下げることでさ

393 ：デフォルトの名無しさん：2009/07/27(月) 19:12:31

パッチが欲しいからgithubに行くと言ってる人がいるとするならば、
その日とは「なんでもいいからpull requestしろや、俺が全部
さばいてやるぜ」というつもりで言ってるんだよね？

394 ：デフォルトの名無しさん：2009/07/27(月) 19:46:47

githubになったって、そこ巡回してpullするリソースがないよ。
現状、Redmineに上がっているパッチだって取り込まれるのに時間かかってるのに。

あと、そんなパッチもtypoの修正ならともかく、たいていはそのままじゃ取り込めない。

395 ：デフォルトの名無しさん：2009/07/27(月) 21:20:40

じゃあ、githubに移行するという話は根拠のないデマなの？

396 ：デフォルトの名無しさん：2009/07/27(月) 21:24:00

githubに移行して欲しいと言う人たちはいる。
また、githubに公式リポジトリのミラーを置く計画はある、こちらはyuguiさんのリソース次第

397 ：デフォルトの名無しさん：2009/07/27(月) 21:25:43

とはいえ、今より敷居が下がるのはいいことだとおもうけどね

なんか今だと関連MLの記事を数年分把握してて、
主要コミッタとのリアルつきあいも欠かさず行って、
一日の何時間かをRubyに捧げる宣言しないとならなくて、
事情があっても辞めるに辞められないようなイメージがあるわw

398 ：デフォルトの名無しさん：2009/07/27(月) 21:59:12

>>397
それ全部満たしてる開発者いないだろｗ

399 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/07/27(月) 22:55:00

それはまつもとさんでもあやしいなぁ……ｗ

401 ：デフォルトの名無しさん：2009/07/27(月) 23:48:33

http://www.atmarkit.co.jp/news/200907/24/ruby01.jpg

なにポーズつけてるんだよ（ｗ

402 ：デフォルトの名無しさん：2009/07/27(月) 23:51:46

これは三つ子と言われても普通に信じるレベル

403 ：デフォルトの名無しさん：2009/07/27(月) 23:58:35

yugui さんにしろ笹田さんにしろ、若いのにすごいなぁっておもった。
おれなんか33の業務系SEだけど、
Ruby にしてもほかの言語にしても、使う側で精一杯だよ。

こういう人たちは、「プログラミング言語オタク」でもあるんだろうな。

404 ：デフォルトの名無しさん：2009/07/28(火) 00:31:24

>>403
人のことを素直にすごいと思えるおまいさんはまだ伸びる素質がある。
なにかにつけ欠点を探して自分を優位にしておかないと気が済まない連中というのが少なからず存在して、
そういうやつは口ばっかり達者でいつまでたっても実力が身につかない。

405 ：403：2009/07/28(火) 01:39:13

>>404
どうもありがとう、コーディングする機会も減ってきたが、まだまだがんばるよ。

406 ：デフォルトの名無しさん：2009/07/28(火) 02:17:08

>>404
でも、いろんな人やら意見を懐疑的に捉えて自分なりに
いろいろ考えるのも楽しいお。
盲目的に「すげー」はかえって学ぶ機会を損失するとおも。

407 ：デフォルトの名無しさん：2009/07/28(火) 07:41:54

何事もバランスが大事

408 ：デフォルトの名無しさん：2009/07/28(火) 08:16:52

>>401
これ新宿駅の紀ノ国屋のところのウッドデッキかな?

409 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/07/28(火) 10:10:21

>>408
秋葉原のUDX1Fのテラス(タリーズ)じゃないの？

411 ：デフォルトの名無しさん：2009/07/28(火) 11:28:55

>>408
Matzの左上に高架線の架線柱が見えるけど、
新宿のウッドデッキは、そこより高い位置に線路はない。

412 ：デフォルトの名無しさん：2009/07/28(火) 13:24:17

なるほど。たしかにささだ氏のホームグラウンド的にもそっちだね。

413 ：デフォルトの名無しさん：2009/07/28(火) 13:29:53

>>409
なんかめんどくさッ！

414 ：デフォルトの名無しさん：2009/07/28(火) 13:41:41

だからgithub持ってくのには消極的反対なんだよ

415 ：デフォルトの名無しさん：2009/07/28(火) 13:48:18

何を言う、コード追加・変更の説得力のベースになるものが
一連の手続きとして試行可能だなんて鼻血が出るほど素晴らし過ぎるじゃないか

これが問題なく終わってれば後は口頭で説得するだけだろ？
最悪取り込まれなくても、「動作可能・動作検証可能」なコードとして存在できる

メーリングリストのどっかにちょろっと書かれたのを個々人が実行、なんてのよりはるかにマシ

めんどくさいというそれそのものには大きく同意はする
でも、githubで公開する時にだけやればいいだけだしさー
pushの前に一連の検証すればとりあえずオッケー、というのだけで安心感違うだろ

416 ：デフォルトの名無しさん：2009/07/28(火) 13:57:01

>>397
> なんか今だと関連MLの記事を数年分把握してて、
十回くらい上がるたびに同じような理由で却下されたような提案を、また得意
顔して出してくるやつがいたら、誰だってうんざりするだろ。

> 主要コミッタとのリアルつきあいも欠かさず行って、
不要。tsなんて誰も顔も知らなかった。

> 一日の何時間かをRubyに捧げる宣言しないとならなくて、
宣言なんて無意味。自分が必要だと思ったことをすればいいだけ。

> 事情があっても辞めるに辞められないようなイメージがあるわw
正直いってライブラリとか新規プラットフォームとかは、追加したはいいけど
後は知らんぷりで全然メンテしてくれなくなっちゃって困りまくり、という例
も多々あるので、継続できないのなら無理に入れてほしくない。

417 ：デフォルトの名無しさん：2009/07/28(火) 14:13:25

ライブラリや新規プラットフォームは、
メンテナと「サブメンテナ」を用意しないと対応しない、でもいいと思う。

もちろん「サブメンテナ」も活動しなくなる可能性はあるけど
少しだけフェイルセーフ。

418 ：デフォルトの名無しさん：2009/07/28(火) 14:14:49

メンテナを抜ける場合は別のメンテナ1人かサブメンテナ3人を紹介しないと抜けられないというのはどうだろう

419 ：デフォルトの名無しさん：2009/07/28(火) 14:18:02

ああっ、教祖や経典を崇める感じでシューキョーっぽかったRubyがとうとうマルチに手を

420 ：デフォルトの名無しさん：2009/07/28(火) 14:19:38

いいね。

あとブログや twitter なりでライブラリ保守されていないから改良した、
野良パッチをあてた、と書いている人を「スカウト」する積極さがあってもいいかも。

421 ：デフォルトの名無しさん：2009/07/28(火) 15:04:51

必要なのは優秀なコード書きじゃない
有象無象を束ねる優秀なマネージャー

まーつまりあれだ、いつも会社でウンザリしながらやってることを、
レベルも認識もバラバラの目の前にいない素人混じりの大人数に対して
金銭的報酬もないまま本来余暇であるはずの時間をつぎ込んで捌くような人が必要だということだ

422 ：デフォルトの名無しさん：2009/07/28(火) 15:12:12

>> 事情があっても辞めるに辞められないようなイメージがあるわw
>正直いってライブラリとか新規プラットフォームとかは、追加したはいいけど
>後は知らんぷりで全然メンテしてくれなくなっちゃって困りまくり、という例
>も多々あるので、継続できないのなら無理に入れてほしくない。

Rubyの内部事情ってそんなに酷いん？

423 ：デフォルトの名無しさん：2009/07/28(火) 15:18:34

ここ数年の Ruby の(リリース)マネージャは個人的には疑問だなぁ。
もっとアジャイルなほうがいいと感じてる。
優秀なコーダなんだから、
マネージャはモチベーションを上げたりするような
ファシリテータやコーチ的なのが合う気がする。
なんだか古臭いマネージングな気がして。

424 ：デフォルトの名無しさん：2009/07/28(火) 15:19:40

真の人柱だな…

425 ：デフォルトの名無しさん：2009/07/28(火) 15:34:36

>>422
Rubyの開発しやすさ、Rubyの中ではなんでもできる、作ってて超楽しい、というのが
物理的に広い開発では極めて悪い方向に作用している

これまで破綻しなかったのはそれこそ教祖様の数多の一声（の、却下）があってこそ

426 ：デフォルトの名無しさん：2009/07/28(火) 15:38:45

誰もやりたがらないことは
やらずに放っとけばいいよ
そのうち誰かがやってくれるから

これが Ruby クオリティ

427 ：デフォルトの名無しさん：2009/07/28(火) 16:43:24

tsって誰

428 ：デフォルトの名無しさん：2009/07/28(火) 16:54:40

>>425
Ruby標準・添付ライブラリが比較的マトモで、Railsがおおむねカオスなのはまつゆきの存在が大きい
Rubyからまつゆきを取り除くと、たぶんRailsになる

429 ：デフォルトの名無しさん：2009/07/28(火) 18:27:01

コントロールブレイク　ネタにマジレスしているakrたんに萌えた。

430 ：デフォルトの名無しさん：2009/07/28(火) 18:33:34

> あとブログや twitter なりでライブラリ保守されていないから改良した、
> 野良パッチをあてた、と書いている人を「スカウト」する積極さがあってもいいかも。

blogやtwitterに書きっぱなし、野良パッチ当てっぱなしの人をスカウトすると、
結果がどうなるかは、まぁ、目に見えてますよね、そういうのはいやなんだ。

一方で、ruby-devにパッチ投げまくってくる人とか、IRCでパッチ書いてる人とかは、
誘ったりしてるよ。

> ここ数年の Ruby の(リリース)マネージャは個人的には疑問だなぁ。
それ以前の惨状をご存じの上で仰っておられるのでしょうか・・・。
まぁ、外から見ていると印象は違うかもしれない。

というか、coreの人間はtrunkしか見てないんで、リリース直前でもない限り、
リリースマネージメントはあんまり関係ないよ。
むしろそんな調子なのでちゃんとリリースマネージメントをやってくれる人がいないと、
いつまでたってもリリースできないんだ。

>>425
> Rubyの開発しやすさ、Rubyの中ではなんでもできる、作ってて超楽しい、というのが
> 物理的に広い開発では極めて悪い方向に作用している

Rubyと言っても、>>416のライブラリってのは標準添付な拡張ライブラリだろうから、
ソースは基本的にCだよ、Ruby使えるから素より遙かに楽だけど。

まぁ、そういういくつかのライブラリでの話であって、
全体的にそこまでの惨事になっているわけではないのでご安心ください。

>>428
あと、akrさんの存在もかなり大きいと思う。

431 ：デフォルトの名無しさん：2009/07/28(火) 18:51:43

そもそも、今までのコミッタってどうやってコミッタになってるの？
誰かに推薦されたとかそんな感じ？

どういう形でコミッタになったのか、ということと、コミッタになった後
どんな活動を続けているかand/or続けなくなってるか、ということって、
それなりに相関があるんじゃないかと思うんだけど、どうかな？

432 ：デフォルトの名無しさん：2009/07/28(火) 18:55:43

「惨状」とは思わなかったなぁ。

今は締切までに機能追加が間に合わないと、
次のリリースまで待たないといけなくてイマイチ。
期日の厳守のしすぎは目的と手段を見失っている感じ。

あと「惨状」とか「優秀なマネージャ」とか主観が強すぎ。

433 ：デフォルトの名無しさん：2009/07/28(火) 19:48:55

>>430
だからまあ、パッチの都合がよければpull requestを受け入れて、悪ければスルー。以上終了、って感じの
ゆるくて敷居の低いアプローチが求められてるんじゃね。

散々既出のネタに対して過去ログ嫁だのFAQ嫁だのレスしたりFAQ整備したりする必要はなくなるから。
どうせ何かの案が採用される率なんて手法に依らず千三つみたいなもんなんだから
却下がノーコストで提案の母数が増えるならそっちの方がよかろうと。

434 ：デフォルトの名無しさん：2009/07/28(火) 20:08:43

BTS使っているから、何度も寄せられる要望を抽出して、そこを見ろ、でもいいと思うし。

435 ：デフォルトの名無しさん：2009/07/28(火) 23:48:36

おお、Yuguiさん乙だ
自身のブログでgemの多言語化について詳細に書いてる。アクセス集まってるのか心なしか重い。
そういやRubyKaigiまだ見てないな・・・。

436 ：デフォルトの名無しさん：2009/07/28(火) 23:49:41

1.9系の話ね。

437 ：デフォルトの名無しさん：2009/07/29(水) 00:02:05

って一週間前に書いてるじゃん
なんで気づいてなかったんだ俺

438 ：デフォルトの名無しさん：2009/07/29(水) 00:12:05

漏れはとりあえずマニュアル整備してくれてる方々に最大の賛辞を送りたい

439 ：デフォルトの名無しさん：2009/07/29(水) 08:58:31

>>431
ざっとIRCでアンケートを取ったところ(IRCにいるということは現在アクティブであると推察される)、
パッチを投げてたら釣られた人と、立候補が半々くらいだった。

あとは、coreをいじる人とライブラリメンテナでは違いがあって、
ライブラリの場合はある程度完成しちゃうとそれ以降いじらなくなる人がいるかな。
最近ライブラリの追加に否定的な人が多いのはこの辺の事情も影響してる。

440 ：デフォルトの名無しさん：2009/07/29(水) 09:10:28

はッはッはッ、安定したライブラリに手を入れる必要なんてどこにあるんですカ

441 ：デフォルトの名無しさん：2009/07/29(水) 09:13:23

>>423
そうやってexperimentalな機能をとりこみ続けるとカオスになる。
今まで以上にいつまでも安定しない処理系を使ってもらえるか疑問。
ただし、とにかく色々出してみて有用なのを取り込んで安定させるというスタイルに向けて舵を切るべく、その意味でもgit化は期待できる。早くやれ。

個別の機能については「これは重要だから仕様凍結を破れ」と意見すれば受理される余地はある。
だから、メーリングリストで取り入れるべきだと主張すればいい。メーリングリストの敷居が高ければtwitterだっていい。

442 ：デフォルトの名無しさん：2009/07/29(水) 10:09:19

> blogやtwitterに書きっぱなし、野良パッチ当てっぱなしの人をスカウトすると、
> 結果がどうなるかは、まぁ、目に見えてますよね、そういうのはいやなんだ。

443 ：デフォルトの名無しさん：2009/07/29(水) 10:27:17

Rubyにしろなんにしろ属人的なものは減らしていかないと逝けないの鴨知れない
Matzだっていつまでも生きていられる訳じゃないんだし

444 ：デフォルトの名無しさん：2009/07/29(水) 10:33:55

個人の才能による作品を認めない優秀なマネージャ

445 ：デフォルトの名無しさん：2009/07/29(水) 10:35:32

芸術作品を日常使うと不便というのはよくある話

コルビジェの作った建築も雨漏りがしたっていうし

446 ：デフォルトの名無しさん：2009/07/29(水) 10:38:18

>>444
信念を持ってリジェクトできることこそが、マネージャーとして優秀である証
それがすばらしい作品であることと、それを取り込んだものがすばらしくなるかどうかは別

447 ：デフォルトの名無しさん：2009/07/29(水) 10:40:14

コンテストじゃないんだから勘弁してくれ

448 ：デフォルトの名無しさん：2009/07/29(水) 11:02:37

人間としても成熟してこそ優秀なマネージャ

449 ：デフォルトの名無しさん：2009/07/29(水) 11:59:51

>>439
すると、後は非アクティブな人のうち、パッチを投げて釣られた人・立候補した人の比率がどうかを見るといいんでしょうか？

ところでIRCでアンケート取ったとかいうことは、あなたは中の人ですか？

450 ：デフォルトの名無しさん：2009/07/29(水) 12:23:49

そういえば、一応すでにgithubにリポジトリのミラーはあるよ
http://github.com/rubyspec/matzruby/tree/trunk
pushとかpull requestとかはできないけど

>>449
非アクティブな人にはアンケートという技が使えないので、MLあさらないといけないんですよね。
「SSH鍵」とかのキーワードで探せばいいと思うんだけど。

http://jp.rubyist.net/magazine/?FirstStepRuby ちなみにIRCってのはこれ

451 ：デフォルトの名無しさん：2009/07/29(水) 12:24:15

アンケートを取ったのが中の人かどうかが何にどう関係するのかがわからない

452 ：デフォルトの名無しさん：2009/07/29(水) 12:29:51

>>440
> はッはッはッ、安定したライブラリに手を入れる必要なんてどこにあるんですカ
典型的なのはバグ報告が来た場合、セキュリティ絡みだととっても困る。
あとは本体の仕様変更に追従すべき場合、たとえばM17Nですね。

453 ：デフォルトの名無しさん：2009/07/29(水) 12:35:28

それくらいならそのコード読めばだいたい修正個所はわかるんじゃね
作成した人しかコードが触れないという呪いでもかかってるわけじゃなかろう

そのライブラリと分野のプロフェショノー（滑らかな発音）を一人は置く状態にしておく、というのもわかるが
でもそれだと修正要求に応じられるだけのバックグラウンド知識がライブラリメンテナに要求されるな

454 ：デフォルトの名無しさん：2009/07/29(水) 12:40:28

まーそりゃ本体組み込みや添付のライブラリは基本的なライブラリが多い（ことが期待される）から、
ライブラリのメンテナーの知識レベルは高いほうがいいと思う

ネットアクセスライブラリ作ったけど HTTP の知識よくわかんないどうすればいいかな、ではやっぱ困る
せめて、それなりに自分ひとりで意見組み立てた上で他の人のアドバイス募る、くらいでないと

455 ：デフォルトの名無しさん：2009/07/29(水) 12:43:20

>>453
http://www.ruby-lang.org/ja/news/2008/08/23/dos-vulnerability-in-rexml/
こういうのが来て、メンテナと連絡がつかなかったらどうする？

456 ：デフォルトの名無しさん：2009/07/29(水) 12:52:50

些細な変更でも、誰がそれをやるかって言うのはあるな。

457 ：デフォルトの名無しさん：2009/07/29(水) 12:56:19

>>455
いやだから、rexml のソースは読めるだろ
初心者には無理だが、中級者かそれ以上なら首っ引きでなんとでもなるだろ
普段のだらだらした新機能要求ならまだしも、セキュリティバグなら「誰かできる人」がやるべきだろ

たとえば、「メンテナが学会出張中なのでそれが終わってからゼロデイ脆弱性のパッチをリリースします」でいいのか？

458 ：デフォルトの名無しさん：2009/07/29(水) 13:19:27

いいんじゃねえの
メンテナーの責任ってそういうことだろ

459 ：デフォルトの名無しさん：2009/07/29(水) 13:22:01

てか、そもそも、作成者が対応する義理も義務も何もないんだぜ
使って不都合なら、使用者側でなんとかするか、問題のないものに切り替えるべき

460 ：デフォルトの名無しさん：2009/07/29(水) 13:26:41

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/35945
から始まるスレッドにも情報があるんだが、
このREXMLのDOS脆弱性は以下のような悪条件が揃っていた事例であった。
1. セキュリティ絡みのバグ
2. メンテナと連絡がつかない
3. 根本的な解決にはAPIの変更が必要

このため、当初はモンキーパッチを公開し、議論の上で根本的な解決を入れることになった。
議論はruby-dev, ruby-core, 非公開のセキュリティMLで行われた。
議論の結果、REXML::Document.entity_expansion_limitという新APIが追加された。
先述の通りメンテナ不在であったため、これらは前田さんによって行われた。

461 ：デフォルトの名無しさん：2009/07/29(水) 13:28:58

なぜ対応するかというと、はっきり言えば矜持なんだろう
「この状況はマズい」と感じて、「なんとかしないといけないものだ」と考えるから

じゃあ、みんなでよってたかってやればいいんじゃねーの、と思う
緊急用待機のメンテナーなんてなくてもいい
ライブラリ新機能更新用のメンテナーと、みんなが読み解けるように維持されたコード、この2つでたぶん充分だ

462 ：デフォルトの名無しさん：2009/07/29(水) 13:49:33

>>461
> じゃあ、みんなでよってたかってやればいいんじゃねーの、と思う
だめな例としてセキュリティインシデントが挙げられたんだと思うけど

> ライブラリ新機能更新用のメンテナーと、
> みんなが読み解けるように維持されたコード、この2つでたぶん充分だ

パッチ取り込みのコストを過小評価してないかなぁ。
というか、とりあえず誰か先に出てたgithubのミラーをベースに、
Redmineに上がっているバグを修正し、githubにupして、メールベースでpull希望だしてみたら。

463 ：デフォルトの名無しさん：2009/07/29(水) 13:54:42

仕事でRuby使っても大丈夫かどうか不安になってきました

464 ：デフォルトの名無しさん：2009/07/29(水) 14:01:41

誰かメンテナがいたとして、その人が修正コードを出してきたとしても、
「よっしゃ○○さん仕事早ええじゃあ早速コミットします」
じゃないだろやっぱ
それなりに複数の人が検証時間取ったり実はそれほどとってなかったりするだろ

じゃあやっぱ他の人が適当に修正コードらしきもの作ってもそれなりに検証されたりするんじゃね
メンテナのコードなら間違わない可能性が高いというのなら、そもそもバグは起こってないはずでさ

465 ：デフォルトの名無しさん：2009/07/29(水) 14:07:15

>>464
ヒント: メンテナにはコミット権がある

466 ：デフォルトの名無しさん：2009/07/29(水) 14:31:25

もともと、リリースがらみの仕事はまつもとさんに集中していた。
しかし、Rubyも1.8になるとライブラリの肥大化と安定性への期待が高まってきた。
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/40202 1.8.2 リリース前
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/25635 1.8.3
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/25998 1.8.3^preview1予告
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/26135 1.8.3-preview1
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/27265 1.8.3でやっちまった例(logger)
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/27275 1.8.4
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/27429 1.8.4
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/28233 1.8.5

特にリリースエンジニアリングが重要な課題だと認識されたのは、
1.8.3において、リリース直前のloggerに対する変更が原因で、
リリース版の1.8.3でRailsが動作しなかったことではなかろうか。

これにより、リリース直前の機能変更の危険性が開発陣で認知されることとなり、
仕様凍結の必要性が叫ばれることとなった。

その後、1.8.4や1.8.5において、凍結を実施してみたところ、
その感想はおおむね「多少マシになったけどまだダメ」といったところであった。

467 ：デフォルトの名無しさん：2009/07/29(水) 14:39:36

schedule for Ruby 1.8.6
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/30239
1.8.6ではいくつかの大きな変更が行われた。
1つは武者さんのリリースマネージャの就任である。
これは、まつもとさんが1.9への変更に専念できると同時に、
まつもとさんやその他のcore開発者の1.8からの隔離を意味していた。
これにより、1.8系は格段に安定性を増すことが可能となった。

もう1つは卜部さんの安定版メンテナの就任とパッチリリースの導入である。
従来のRubyは、
1. 十分な機能追加があった場合
2. 大きなバグの修正があった場合
にリリースが行われていた。
しかし、これだと特定のバージョン+バグの修正という安定性を重視した
構成をとりづらいというデメリットがあった。

他にも、仕様凍結と併せてブランチを切ることで不要な変更の混入を抑止したり、
さらに長くした凍結期間といった、細かな変更も行われている。

これらの施策によりRuby 1.8.6は「最初のまともな安定版」となることができ、
1.8.6は高い評価を得ることとなった。

468 ：デフォルトの名無しさん：2009/07/29(水) 15:16:19

>>459
実際そういう考えが主流だった時代もあったけど、
今時それはよくないよね、って考えで
かつ実際血を流して対応してくれる人が出てきてくれた御陰で
Rubyは-pxxxのセキュリティパッチ適用リリースが出るように
なったわけで。

そうなるまでは機能追加とセキュリティパッチは
ごちゃ混ぜでリリースされてたわけで。

今考えるとすごい状況だよな

469 ：デフォルトの名無しさん：2009/07/29(水) 15:26:01

github は一度 push したブランチが訂正できないから嫌い
git に「ハッシュ値を変更せずにコミット内容だけ訂正する」みたいなオプションがあればいいのに

470 ：デフォルトの名無しさん：2009/07/29(水) 16:40:07

>>464
もうちょっと地に足をつけた上で提案としてまとめたほうがいいんじゃないかな
それぞれの場面で実際に誰が動くのか、動かなかった場合どうするのか考えないと、
話は進まないよ。

たとえばマスターはsvnのままという前提で行くと、pull requestされたパッチを、
どうやってgitの世界からsvnの世界へと持っていくか、とか。

471 ：デフォルトの名無しさん：2009/07/29(水) 18:14:35

>>469
お前さん、「ハッシュ値」って意味わかっていってる?
それが簡単にできたら、gitの前提が崩れさるだけじゃなく、
セキュリティ的に大騒動が起きるんだが。

472 ：デフォルトの名無しさん：2009/07/29(水) 22:56:33

>>451
答えてくれて嬉しいんだけど、この親切で素敵な人はいったいどこの誰だろう、という私の好奇心が満たされる。

473 ：デフォルトの名無しさん：2009/07/29(水) 23:04:36

>>457
そうだな、中級者かそれ以上なら誰でも直せるかもしれないな。
だから、誰だかわからんけど「誰かできる人」が直してくれるはずだから、
それまで放っておけばいいよな。

と、いうことになったら永久に誰も直さないかもしれないから、最終的には
責任を負うべき「メンテナー」というものが存在してるわけだろ？

474 ：デフォルトの名無しさん：2009/07/30(木) 02:21:46

>>473
まさにそういうことです。
で、メンテナ不在のライブラリは結構すでに多くて、
http://redmine.ruby-lang.org/wiki/ruby/Maintainers
のうち、noneに加えて、まつもとさんと中田さんがメンテナになってるのは、
事実上メンテナがいないのものです。
また、メンテナがアクティブでないものは、why、serのと青木さんのかな。
前田さんのもほとんどメンテナンスされてないかも。

475 ：デフォルトの名無しさん：2009/07/30(木) 02:57:17

層の薄さが

476 ：デフォルトの名無しさん：2009/07/30(木) 04:52:54

>>473
わかってないんだな

どうして緊急性のあるものと緊急性のないものをわざと混同して話すんだ？

477 ：デフォルトの名無しさん：2009/07/30(木) 05:01:59

>>476
Redmineを見れば緊急性のないものがいくつか放置されているのが見て取れると思うんだけど

478 ：デフォルトの名無しさん：2009/07/30(木) 10:43:33

>>476
だから、

緊急性があるかどうかを判断して、
影響範囲を検討して、
修正を行って、

というのを誰がやることになるのかが問題だ、つってんだろ。

479 ：デフォルトの名無しさん：2009/07/30(木) 11:02:25

「緊急度が低い用件」という、何がしかの判断が済んでいるシロモノがあるように見えるのが間違いだな
判断されてるならそれに任せればいいという話にしかならん

「緊急なのか危険なのか誰にも全く判断されずに転がってる要件がいくつもあります」でなければならない

480 ：デフォルトの名無しさん：2009/07/30(木) 11:02:53

メンテナがいなかったり動いていない場合はとりあえず中田さんに振る、
というのが現状なんだが、遅かれ早かれ限界は来る

481 ：デフォルトの名無しさん：2009/07/30(木) 11:06:34

>>479
バグ報告の時点で重要度とか優先度とかあるのおかしいと思うんだ、俺

482 ：デフォルトの名無しさん：2009/07/30(木) 11:08:11

Rubyの赤は中田さんの血の赤というわけか

483 ：デフォルトの名無しさん：2009/07/30(木) 11:21:03

>>481
理想と現実の区別はしような

484 ：デフォルトの名無しさん：2009/07/30(木) 13:21:53

>>481
別に報告者の考えるそれがあるのはおかしくないじゃん
それらは必要なら受付者が変更するものなわけだし

485 ：デフォルトの名無しさん：2009/07/30(木) 14:14:32

本当は、報告されてきたバグや要望を、重要度や優先度をつけつつ担当者に割り振る、
Redmineマネージャみたいな人が必要なんだよね。

486 ：デフォルトの名無しさん：2009/07/30(木) 15:12:37

おまえらその議論の情熱を１０％でもコードにぶつければだな

487 ：デフォルトの名無しさん：2009/07/30(木) 15:21:06

そりゃただの逃避だ
我々に必要なのは神業コードでも大量データでもない

488 ：デフォルトの名無しさん：2009/07/30(木) 15:24:28

そーだな

「オレたちにできるのは愚直にコードを書き続けることだけだ！」

でできたのが山のような未管理のコードとライブラリ
現実見ようぜ現実

489 ：デフォルトの名無しさん：2009/07/30(木) 15:27:27

まぁ、この一連の議論で一人くらいは釣れないかなぁと思っているわけです。
* 新しく登録されるバグを誰かに押し付けるだけのお仕事
(誰に押し付けるかで半年ROMる必要があるか)
* 登録されたバグの中から簡単そうなのを見つけてパッチを作るだけのお仕事
(最初はお作法にあってないとかで、せっかく書いたパッチを書き直されるかもしれないけどめげない)
* 英語のわけのわからん機能追加に対して「何寝言言ってるんだバカ」と英語で答えるだけのお仕事
とかが君を待ってるぜ

490 ：デフォルトの名無しさん：2009/07/30(木) 15:31:54

抜けるときに10人生け贄、もとい後継者を紹介するみたいな闇ルールがなければ......

実は>>489も後継者探しなのではと疑ってしまう猜疑心の強い俺

491 ：デフォルトの名無しさん：2009/07/30(木) 15:39:34

特にどこかメンテナンスする義務を負わないように逃げまくって、
気の向いたときに気の向いたところを直すとかにすれば大丈夫だよ。

492 ：デフォルトの名無しさん：2009/07/30(木) 15:53:30

>>420
> あとブログや twitter なりでライブラリ保守されていないから改良した、
> 野良パッチをあてた、と書いている人を「スカウト」する積極さがあってもいいかも。
それやると、みんな沈黙するという結果に至る。

493 ：デフォルトの名無しさん：2009/07/30(木) 16:27:23

メンテナーがメンテナンスで食っていけないかぎり、この問題は解決しないのでは？

494 ：デフォルトの名無しさん：2009/07/30(木) 16:29:19

なんらかの報酬か褒賞か報奨はあってもいいかなとも思うが、そんなんないのが普通だよなとも思う

すぱっしょさんくすに本名載せたるから名刺代わりに使え、というのが限界かと(w

495 ：デフォルトの名無しさん：2009/07/30(木) 16:45:11

Ruby会議を利益が出るようにして、メンテナーに配分とか。

496 ：デフォルトの名無しさん：2009/07/30(木) 16:46:31

税金でメンテナーの給料を出す様に民主党のマニフェストに入れて貰うとか。

497 ：デフォルトの名無しさん：2009/07/30(木) 17:13:53

>>492
> blogやtwitterに書きっぱなし、野良パッチ当てっぱなしの人をスカウトすると、
> 結果がどうなるかは、まぁ、目に見えてますよね、そういうのはいやなんだ。
の発言のほうが沈黙するだろｗ
こんなの書いててすみません、みたいな。

498 ：デフォルトの名無しさん：2009/07/30(木) 17:38:44

やっぱり金だよな

499 ：デフォルトの名無しさん：2009/07/30(木) 18:03:34

Rubyビジネスなんとかで金出して優秀なマネージャをフルタイムで雇えばいいじゃん。

500 ：デフォルトの名無しさん：2009/07/30(木) 18:22:14

他のオープンソースプロジェクトって、どうやって回してるんだろう

501 ：デフォルトの名無しさん：2009/07/30(木) 18:33:17

>>494
> なんらかの報酬か褒賞か報奨はあってもいいかなとも思うが、そんなんないのが普通だよなとも思う

報酬をもらわないうちは、これの価値は無限大と思っていられる。

報酬なんか出したら、みんな手を出さなくなってしまう。

502 ：デフォルトの名無しさん：2009/07/30(木) 18:35:39

>>494
> すぱっしょさんくすに本名載せたるから名刺代わりに使え、というのが限界かと(w

ぼくの知覚圏内では、パッチ送って「ぼくの名前出さないで」な人は結構多いん
だが、Ruby宇宙ではそんなことないのか?

503 ：デフォルトの名無しさん：2009/07/30(木) 18:40:07

見返りが欲しい人は名前載せてもいいよそれくらいしかできないよ、という話かと
名前別にいらない、という人は少なくないな

504 ：デフォルトの名無しさん：2009/07/30(木) 18:58:59

>>501
誰もメンテナンスしていないライブラリ群をメンテナンスするには、フルタイムのメンテナーがいないと厳しい。

505 ：デフォルトの名無しさん：2009/07/30(木) 19:00:14

そんなことよりまあ聞いてくれよ、github で公開されてるライブラリをてきとうにフォークして、
それなりに分類になってるブランチを3つくらいいろいろコミットして push したら、
「Network」のとこの自分のアカウントのところがめっちゃ太く長く横に伸びてて凄く恥ずかしいんだが

うん、いや、それだけ
よく考えたらフォークした結果を push して公開する意味ってあまりないよね
自分でだけ使ってりゃ充分だもんな

506 ：デフォルトの名無しさん：2009/07/30(木) 19:08:02

>>504
Rubyでニート脱出のフルタイム在宅ワークがあります
（中級程度のCとRubyの知識があり各種ネットプロトコルとソケットを低レベルで理解しLinuxプログラミングとライブラリ作成の経験があって大規模ソース管理への造詣もある場合は業務未経験でも大歓迎！）
と煽るのはどうだろう

507 ：デフォルトの名無しさん：2009/07/30(木) 19:28:23

>>504
>>501はトンチンカンだった。ありゃ開発者のことだな。
メンテナはどっかのオプソ系会社の社員が仕事でやってても
おかしくはないな。

508 ：デフォルトの名無しさん：2009/07/30(木) 19:31:39

>>506
Rubyの求人ってそんなんばっかだよな
注釈や他の要件が長くて、しかもそっちが必須
だったら最初からRubyって書かないほうがスキルの高い人集まるだろうに

509 ：デフォルトの名無しさん：2009/07/30(木) 19:38:03

TTYとRUBYって似てるよね

510 ：デフォルトの名無しさん：2009/07/30(木) 20:38:34

>>508
「Ruby」って書くと、「注釈や他の要件に書かれた事柄を一人でできる人」って意味になる

511 ：デフォルトの名無しさん：2009/07/30(木) 20:41:02

Ruby1.9.1 のこないだ出たやつを Ubuntu にインストールしようと思ったんだけど、
なんか configure に必要なオプションってある？
だいぶ前に p0 のをインストールしたときは readline とか openssl とか指定しないといけなかった気がしたんだけど、
まだ自動で探さない？

512 ：デフォルトの名無しさん：2009/07/30(木) 21:49:30

Firefoxは、右上の検索バーで収益を上げているみたいだけど、Rubyも
何かできないかな？

MLに広告を載せるとか、www.ruby-lang.org/に広告のせるとか。

ユーザの負担にならない程度に、収益を上げる方法を考えるべきでは？
あまり広告主の影響受けるのも良くないけど。

現状は収益源って何かあるの？

513 ：デフォルトの名無しさん：2009/07/30(木) 21:58:40

>>512
誰の?

514 ：デフォルトの名無しさん：2009/07/30(木) 22:08:01

カッコイイ人が多いイメージのある県ランキング
http://ranking.goo.ne.jp/ranking/999/prefecture_coolboy/p5/

515 ：デフォルトの名無しさん：2009/07/30(木) 22:11:37

>>492
それはやっぱり抜けるときのルールが不明確だからじゃね?

「どうやったら足抜け出来るかわからない」世界に飛び込むのって命がけじゃん。
特に期待されてるような「責任感の強い人」ほど責任が全うできるかわからなくて
二の足を踏むのでは?

例えば任期を一年単位にしてみるとかさー。

516 ：512：2009/07/30(木) 22:29:05

誰の収益源かというと、何と言っていいのか分からないけど、Rubyのメンテ
ナンスをしている人達、そのチームとしての収益なんだけど。

現状は収益0円？　だとすると、PCの電気代がかかるんで、むしろ
個人でお金を払ってメンテナンスしているんですかね。

517 ：512：2009/07/30(木) 22:36:58

メンテナ募金というか、寄付を募集するのも、まずいんですかね。
アメリカは、寄付の文化がありそうなので、Rubyなら集まりそうな
気もするけど。

フルタイムで働く賃金が出せなくても、足しになればいいのでは。

518 ：デフォルトの名無しさん：2009/07/30(木) 22:41:09

yes

519 ：デフォルトの名無しさん：2009/07/30(木) 22:49:54

BSD系とかだと寄付を受け付けてるし
OpenBSDはネットで入手できるものと中身は同じと断った上で
リリースのパッケージ売ったり、Ｔシャツ売ったりしてるな。

あっちはフルタイムの開発者もいるしセキュリティオフィサーもいるなあ。

フルタイムって意味ではぶっちゃけJRuby界隈に頼んだら受けてくれそうな気もするけど、
企業リソースに致命的なパートを依存すると完全にキンタマ握られかねなくて
頼むに頼めないってのもあるか。

520 ：デフォルトの名無しさん：2009/07/30(木) 22:55:12

Runyってオスだったのか

521 ：デフォルトの名無しさん：2009/07/30(木) 22:55:14

なにより、「フォークは自由だがRuby自体は俺のもんだ」って教祖様が常々
おっしゃってるので、組織的な動きがしにくいってのもあるんじゃね？

522 ：デフォルトの名無しさん：2009/07/30(木) 22:56:52

向かうところ敵なしの勢いのCPAN界はどうなってるよの。

523 ：デフォルトの名無しさん：2009/07/30(木) 23:00:20

>>517
一応Ruby Associationってのがあるんだけど、個人宛だとお金の配分とか受け渡しとかが面倒なんだよね。
個人的にはコンパイルファームが欲しいんだけど、まぁそれの管理者も必要になってしまうので云々。

ちなみにWebサーバやリポジトリ用のマシンは今NaCl持ちかな。

いきなりメンテナだと感じもわからないだろうので、まずはIRCから始めてみると、
コミッタの生態もつかめてよろしいかと思います

524 ：デフォルトの名無しさん：2009/07/30(木) 23:02:27

>>517
開発の仕事で食ってるサラリーマンからすると、たまに中途半端な金なんか
渡されても嬉しくもなんともない。
金が関わらないから、遊びという名目で仕事の外で付き合っていられるんで
あって、プロに金渡すなら、労力に見合った額をきっちり出してもらわんと困る。

>>519
Engine Yardという会社が、しばらく前からruby 1.8.6の保守を担当しているよ。
フルタイムの従業員を一人そのために割り当てている。

525 ：517：2009/07/30(木) 23:14:16

なるほど。確かに、仕事で開発している人なら、金とは関わりない世界で
携わりたいのは理解できる。

人手が足りなくて負担になってるみたいなんで、書き込んでみたんだけど。
私が少し考えて解決策がでるぐらいなら、もともと問題になってないよなあ。

526 ：デフォルトの名無しさん：2009/07/30(木) 23:15:36

>>524
技術の安売りはしない。これはあくまで仲間内/趣味での話
......って整理をしてるケースは多いよね。
haunとかもそうだった気がする。

527 ：デフォルトの名無しさん：2009/07/30(木) 23:19:17

>>525
いやその前に、あんたが何を「問題」視してるのかがわからんと話にもならん

RubyはRubyでそれなりの発展を（まだ）続けているし、ここまで来たらたぶん
Matz（やひょっとしてささださん）一人になっても、本人らが飽きず・食えてる
限りはそれなりに続くだろう

528 ：525 ：2009/07/30(木) 23:29:37

問題っていうのは、489の書き込みのように、人手が足りないこと。
人手を確保するにはお金じゃないの？という議論があったんで。

私は、「金が関わらない世界で遊びでやりたい」という気持ちを理解して
いなかったんで、的外れなことを言って申し訳ない。

529 ：デフォルトの名無しさん：2009/07/30(木) 23:34:35

>>528
そこは統一見解ではないというかインナーサークルと外側とで見解が違ったりするんじゃない?

あと金にしても端金なのか契約の元普通に人を雇える額なのかでも違ってくると思う。
実際未踏のお金(国からの補助金)でYARVは開発されてたわけだし。

530 ：デフォルトの名無しさん：2009/07/30(木) 23:39:51

>>526
「技術の安売りはしない」なんていう高尚な話じゃないんだ。

フルタイムの本業を持ってるメンテナがいて、本業が忙しく
なってRubyに手を出す時間が取れなくなったとする。
この場合、そのメンテナ個人にちょっと金を渡しても、問題は
全く解決しない。
個人が金を貰っても本業の忙しさには何の影響もないんだから。

メンテナの時間を確保するためには、そのメンテナが本業の
代わりにRubyをいじれるだけの金を出す、つまりフルタイムで
雇用してやるか、または、メンテナの所属する会社に適切な
代金を払ってメンテナの時間を買うか、どちらかしかない。

531 ：デフォルトの名無しさん：2009/07/30(木) 23:40:46

基本、締め切り付きで何かのアウトプットを求めるなら、
善意へ期待じゃなくて何らかの代価を払うべきとは思うけどね。

それこそセキュリティパッチみたいに「気が向いたら」だとマズいようなケースもあるし
そこぐらいはフルタイムの担当を雇いつつ代価を求めてもいいと思うけどね。

まあ陳腐な例だけどそれこそＴシャツ売るでもいいわけだから。

532 ：デフォルトの名無しさん：2009/07/30(木) 23:43:20

問題はだ。フルタイムで誰ならおまいら納得するんだと。
おまいらが期待するような人材は、大概他でバリバリやってるんだってば。

今のところmatzがフルタイムぽいんだが不満なのか？

533 ：デフォルトの名無しさん：2009/07/30(木) 23:46:21

>>528
「金が関わらない世界で遊びでやりたい」と言ってる
わけではなくて、「遊び」という形で背負える程度の
責任しか背負いようがないだけ。

個人に小銭を渡しても、使える時間が増えるわけじゃ
ないんだから、背負える責任の大きさは変わらない。
だから、使える時間を増やせるほどの額じゃなければ
受け取るわけにはいかないのだ。

534 ：デフォルトの名無しさん：2009/07/30(木) 23:46:47

matzがフルタイムっぽいのは理解したうえで、さらに人手を増やすには
どうしたらいいか、という話じゃないの。
matzが健在ならオールオッケイなのか？

535 ：デフォルトの名無しさん：2009/07/30(木) 23:48:29

じゃあどこまで規模を広げるべきか、そういう話になるはずだよな。
なってるか？
金があるから大きくなるんじゃなくて、大きくするために金が必要
ってのが普通の流れだよ。

536 ：デフォルトの名無しさん：2009/07/30(木) 23:51:27

何かアプリ作れよ。世界中で使われればRubyに興味を持つやつが増える。
ビジネス的な価値を見いだすところが出れば金が集まる可能性も高まる。

537 ：デフォルトの名無しさん：2009/07/30(木) 23:52:50

どこまで人を貼り付けないとマズいのか、ってところだよな。
1.8.6にフルタイムで人が貼り付いてるのは多分Rails関連でしょ?

あとはサポート継続中のリリースに対してセキュリティ対処出来る分だけの
リソースがあるなら当面はいいんじゃないかなと思うけど。

538 ：デフォルトの名無しさん：2009/07/30(木) 23:54:51

matzは布教活動で忙しいんだよ。

539 ：デフォルトの名無しさん：2009/07/31(金) 00:09:56

>>536
Tracの前にRedmineが作られていれば、キラーアプリになれたかもね。
MovableTypeと同等のRuby製品があって、ちょっとだけ早く出ていれば、
Rubyの方がレンタルサーバで優遇されたかもね。
PHP5と同時期にmod_rubyというか、mod_railsがあれば、そっちにも
人は流れたかもね。インストールの手間は大して変わらんし。

結局、Rubyは何かを作ってきた、世の中を動かして来たって実績がほとんど無いんだ。
常にアンチテーゼを提出してみるだけの文化が染みついてるんだ。

万年野党もいいじゃないか
（って感じで関わる人間が多い気もするんだ実際）

540 ：デフォルトの名無しさん：2009/07/31(金) 00:13:33

>>532
matzはコミット権の剥奪を申し渡されるようなタイプだから、
仕様策定者、開発者としてはともかく、保守担当者としては
完全に役者不足。

541 ：デフォルトの名無しさん：2009/07/31(金) 00:20:20

向き不向きってのはあるからね

ある意味フルタイムで雇っているなら自分の思いと求められていることとが
相反したときでも契約をよりどころに割り切って行動できるかもしれないけど、
その辺ナシで自分の思いと反する行動をとるって負担度が高いよね。

542 ：デフォルトの名無しさん：2009/07/31(金) 00:27:46

>>527
実際のところ、開発に関しては放っておいても全然問題は
ないだろうね。
今まで同様、なんとなく続いていくだろう。

問題は、何度も出ているように、保守。

543 ：デフォルトの名無しさん：2009/07/31(金) 00:37:10

>>539
portupgradeとかtDiaryとか。
まぁ、Rubyは世界を変えるためのものじゃなくて自分の日常をちょっと便利にするためのものなんで、(Railsは知らんよ)
そういう意識の人は多いかもね。

544 ：デフォルトの名無しさん：2009/07/31(金) 00:38:32

>>539
Tracのお陰でpython人口が増えたとも思えない。敢えてrailsをキラーアプリと言わないのも意味不明。
今せっかくRubyの人気が世界中で高まってきているところで、ライブラリ1.9への対応という難題が上がってきていて、今までの様になんとなく誰かがやるのを待つっていうのは、評判を悪くすることになりはしないか？
野党でもいいというのは、他の言語もバリバリできるできる人の発想。凡人は、特化することによってしか活路はない。matzは凡人用のlispとしてRubyを作ったと言ったら、穿ちすぎ？

545 ：デフォルトの名無しさん：2009/07/31(金) 01:09:23

なるほど、こういう人たちがいるがために今の状況があるわけか

546 ：デフォルトの名無しさん：2009/07/31(金) 01:21:50

>>544
Railsは実際に依存している1.8.6がRails関連の金で保守されてるからでしょ。
悪く言えばそこでもう切り離されちゃってる。

547 ：デフォルトの名無しさん：2009/07/31(金) 06:42:33

結局、保守担当者として1人フルタイマーが必要ということ？

Railsが1.9に依存するようになれば、企業が、保守担当者（保守のみ）の
人件費を負担してくれるようになるかな。

548 ：デフォルトの名無しさん：2009/07/31(金) 07:41:39

国がΣプロジェクトに費やしたお金を考えると、メンテナーの二人や三人を税金で賄ってもどうってことはない。

549 ：デフォルトの名無しさん：2009/07/31(金) 08:04:28

Rubyが未踏に選ばれたのは「国産だから」だよね

550 ：デフォルトの名無しさん：2009/07/31(金) 08:11:57

>>548
今まで浪費してきたんだから次の浪費も許されるべきだ、
なんて論法だと身代が潰れるぞ

せめてこうこうこういう理由で必要だから、って言い方にしないと

551 ：デフォルトの名無しさん：2009/07/31(金) 08:26:32

>>549
選ばれる以前の話で、未踏の応募資格は日本人または在日であること

552 ：デフォルトの名無しさん：2009/07/31(金) 08:28:39

>>551
？

553 ：デフォルトの名無しさん：2009/07/31(金) 08:59:38

>>550
済まん。余計な事を書いた。
あの無駄になった２００億以上のお金の何分の一でもあればな～とつい思ってしまった。
KAMEプロジェクトのように、国際貢献になるから、予算つけてくれないかなと思わざるを得ない。

554 ：デフォルトの名無しさん：2009/07/31(金) 09:08:11

そしてgoogleからの圧力によりスーパー301条の対象に。

555 ：デフォルトの名無しさん：2009/07/31(金) 10:10:54

やっぱりお金と人を投入すれば
速くなって使いやすくなって
JavaやPerlやPHPを駆逐していくんだらうか

556 ：デフォルトの名無しさん：2009/07/31(金) 10:18:45

原理的にそれほど速くはならんだろ

そりゃ歴代Rubyの中ではどんどん速くなるだろうが、JavaやPerlにはもともと敵わない
てきとーに作られた中規模Javaプログラムは、必死でチューニングした中規模Rubyスクリプトよりもたいてい速い
応答速度が速いほうがいいプログラムの需要はどうあっても尽きないから、駆逐は無理だ
Rubyスクリプトが高速に動作する環境を用意した場合、他の言語のプログラムは爆速で動く

というわけで、ハードウェア大国日本の面目躍如としてRuby専用CPUの開発をだな

557 ：デフォルトの名無しさん：2009/07/31(金) 10:21:51

YARVチップですか

558 ：デフォルトの名無しさん：2009/07/31(金) 10:33:10

>>556
そういう姑息な真似をしないとPerlより速くならないRubyはクズ
まで読んだ

559 ：556：2009/07/31(金) 10:34:34

>>557
YARVって何？

560 ：デフォルトの名無しさん：2009/07/31(金) 10:46:53

>>559
血税を投入してJRubyより劣った仕組み

561 ：デフォルトの名無しさん：2009/07/31(金) 10:53:02

スピードなんていらない。使いやすければそれでいい。
早いプログラムがほしけりゃFortranで書いてスパコンで実行させるからさ。
欲しいのはパパッと書けて１０秒ぐらいで忘れられるコードだよ。

ただ、rubygemsはno-rdoc no-riをつけないと遅くてたまらん。ああいうところは
改善しないのかな

562 ：デフォルトの名無しさん：2009/07/31(金) 11:02:23

rubygem 開発陣のマシンが超パワフルなので問題ありません

563 ：デフォルトの名無しさん：2009/07/31(金) 11:02:37

>>560=本物の>>556乙

564 ：デフォルトの名無しさん：2009/07/31(金) 11:06:05

>>562
バージョン 0.x 時代の YAML 展開ハングアップのことまだ根に持ってるのか(w

565 ：デフォルトの名無しさん：2009/07/31(金) 11:25:14

シェフのまかないつきRubyエンジニア求人来た！これで勝つる！
ttp://headlines.yahoo.co.jp/hl?a=20090731-00000000-sh_mar-sci

566 ：デフォルトの名無しさん：2009/07/31(金) 11:36:05

>>564
Debianユーザにとっては笑えない…こないだのlennyリリースまでずーっとこの問題抱えざるを得なかったから

567 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/07/31(金) 12:10:09

>>567
後者しかない

569 ：デフォルトの名無しさん：2009/07/31(金) 12:18:50

前者もエンコーディングが合ってるからマッチはするはず

irb> /#{'わんわんお'.force_encoding(Encoding::ASCII_8BIT)}/ =~ 'わんわんわんお'.force_encoding(Encoding::ASCII_8BIT)
6

570 ：デフォルトの名無しさん：2009/07/31(金) 12:24:26

/#{'好'.encode("EUC-JP").force_encoding(Encoding::ASCII_8BIT)}/ =~
'テスト'.encode("EUC-JP").force_encoding(Encoding::ASCII_8BIT)
ダメな例

571 ：デフォルトの名無しさん：2009/07/31(金) 12:26:52

ていうか、実は両方ダメ
/#{'表'.encode("sjis").force_encoding(Encoding::ASCII_8BIT)}/ =~
'表'.encode("sjis").force_encoding(Encoding::ASCII_8BIT)

572 ：デフォルトの名無しさん：2009/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 ：デフォルトの名無しさん：2009/07/31(金) 12:45:30

あ、うん、ここだけ前時代的問題が噴出するよね

# -*- coding: utf-8 -*-
require 'open-uri'
uri = "http://pc12.2ch.net/test/read.cgi/tech/1246174168/571n"
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 ：デフォルトの名無しさん：2009/07/31(金) 13:04:53

CSIだからJavaみたいにユニコードリテラル表現を用意しておいて
最悪ファイル上の非ASCII文字列はnative2asciiつかうって逃げ道も美しくないしなあ

575 ：デフォルトの名無しさん：2009/07/31(金) 13:07:06

外人さんって force_encoding と ASCII_8BIT 好きだよね

576 ：デフォルトの名無しさん：2009/07/31(金) 13:12:05

狂犬発動してUTF8をデフォルトエンコーディングにしておけばこんなことにはならなかったのに…
Windows憎しで避けてたらLinuxすら標準になっちゃったのにな。

577 ：デフォルトの名無しさん：2009/07/31(金) 13:13:39

WindowsではいまだシフトJISが通らないと困ることも多いだろ。
UTF-8で統一強行したらみんな不幸だわ。

578 ：デフォルトの名無しさん：2009/07/31(金) 13:19:44

>>576
Shift_JISのHTMLを読み込んだらUTF-8になってるってこと？

579 ：デフォルトの名無しさん：2009/07/31(金) 14:37:14

force_encoding ってバイト列のほうは変更しないから何度繰り返しても大丈夫だよね？

580 ：デフォルトの名無しさん：2009/07/31(金) 15:01:13

>>573
文字を文字として扱いたいときには、きちんとエンコーディングをつける。ただそれだけのこと。
バイナリとして操作したらはまるにきまってる。

>>576
そういう問題ではないと思うけど。

>>579
まぁ、そうだけど、なんで何度も繰り返したいの？

581 ：デフォルトの名無しさん：2009/07/31(金) 15:47:41

あ、1.9の話してる

クラス変数って継承されるの？継承されないの？

582 ：デフォルトの名無しさん：2009/07/31(金) 15:57:32

全パターンありそうだな
ttp://www.google.com/search?hl=ja&safe=off&num=50&q=Ruby1.9+%22%E3%82%AF%E3%83%A9%E3%82%B9%E5%A4%89%E6%95%B0%22+%E7%B6%99%E6%89%BF%7C%E3%82%B5%E3%83%96%E3%82%AF%E3%83%A9%E3%82%B9&lr=lang_ja

583 ：デフォルトの名無しさん：2009/07/31(金) 16:37:00

>>580
>まぁ、そうだけど、なんで何度も繰り返したいの？
繰り返したいんじゃなくて一回しか呼ばれないことを保証できないんじゃない?
ライブラリ的なものを作ってると悩むかもしれん。

584 ：デフォルトの名無しさん：2009/07/31(金) 16:53:27

>>581
される、でFA。

継承というのもまた違う気がするが。共有というべきかな。

585 ：デフォルトの名無しさん：2009/07/31(金) 17:17:09

>>582
どうしてこうなった…

586 ：デフォルトの名無しさん：2009/07/31(金) 17:55:50

あれ、「1.9ではクラス変数は継承されない」という説明があるのはなんで？

587 ：デフォルトの名無しさん：2009/07/31(金) 19:56:26

>>561
無理だろう
仮に、rubygems開発チームが改善する気になってくれたとしても
現時点でrdoc＆ri生成がデフォルトになってる以上、もうどうにもならんと思う

そもそも最初から、rdocとriの自動生成なんてやるべきではなかった
発想がいくらなんでも富豪的すぎる

588 ：デフォルトの名無しさん：2009/07/31(金) 21:37:42

ttp://shyouhei.tumblr.com/post/152842980/ruby
gitktkr

589 ：デフォルトの名無しさん：2009/07/31(金) 22:55:02

ｷｬｰｼｮｳｻｰﾝ

これは抱かれてもいいレベル

590 ：デフォルトの名無しさん：2009/07/31(金) 23:10:48

30時間はすげーな、mput超乙
しかもこれから来るpull requestを全部捌くわけ？

591 ：デフォルトの名無しさん：2009/07/31(金) 23:17:08

さて、git.ruby-lang.orgへの移行はどれくらい先になるか

592 ：デフォルトの名無しさん：2009/07/31(金) 23:38:01

卜部おにーさんは格好良いなあ

593 ：デフォルトの名無しさん：2009/08/01(土) 05:24:25

>>587
それこそrubygems開発陣のマシンでは「ちょっと待つだけ」だったんだろうな

594 ：デフォルトの名無しさん：2009/08/01(土) 06:13:33

>>577
それはない

595 ：デフォルトの名無しさん：2009/08/01(土) 07:24:26

1.9.1で動いてたライブラリやスクリプトが1.9.2で動作しなくなる可能性って今のところどのくらいある？

596 ：デフォルトの名無しさん：2009/08/01(土) 07:40:25

1.9.1で動作してるなら「めったに無いんじゃないかなー」という程度
まだ仕様が固まったわけじゃないからはっきりとはなんとも

「1.9.2を見据えるとやらないほうがいい書き方」というのは今んとこ無いはず

597 ：デフォルトの名無しさん：2009/08/01(土) 10:44:17

そろそろ RAA for 1.9 作って未対応のものを締め出すのがいいと思うんだ

598 ：デフォルトの名無しさん：2009/08/01(土) 10:44:59

1.9系はスルーして2.0から使うのが本道

599 ：デフォルトの名無しさん：2009/08/01(土) 11:36:18

>>598
書き込むスレ間違えてますよ
ttp://pc12.2ch.net/test/read.cgi/tech/1248487404/

600 ：デフォルトの名無しさん：2009/08/01(土) 14:34:15

そろそろ移動

loopとtimesが似てるとは思わない、そもそもloopにカウンタがほしいとも思ってない
でもあれば便利ってのは理解できる

Kernel#loopが存在している上で新たにIntegerにメソッドを加えれば
単に「繰り返す」ではなく「（ある値から）数え上げながら処理を繰り返す」という意味になる（できる）し
それがtimesの「ある値まで数え上げながら処理を繰り返す」と対称だということ
（timesのメソッド名から考えれば「指定回数繰り返す」なんだけど、ブロック引数取った場合には）

つまり数値が始点か終点となるかの違い
ただ始点のデフォルトが0なのに対して終点のデフォルトは極大だから終わりがない

でもInteger#loopという名前は初めから微妙だと感じてるし
そのせいで批判されまくってるんじゃないかと
0.start {|i| puts i }
やっぱり名付けのセンスないな・・・

601 ：デフォルトの名無しさん：2009/08/01(土) 18:55:13

まあ1.9にしたい香具師ががんばって人柱に成ってれば良い。
それまで今までの互換が有る1.8使ってるから。

信者増やして金儲けしたいなら、リナックスVISAクレジットカードみたいにルビークレジットカードでも作ると良いのかもな。提携カードビジネスは儲かりそうだ。
どんどん宗教法人の様層を呈して来て、松本教祖に金が集まる仕組みに成って来たな。

602 ：デフォルトの名無しさん：2009/08/01(土) 19:00:51

nokogiri-1.3.3のtest配下に2ch.htmlとかが増えてるんだが
何があったんだw

603 ：デフォルトの名無しさん：2009/08/01(土) 19:31:20

そりゃあろいんの「2チャンミテマスヨ」という無形のプレッシャーに決まってるじゃん

whatchanged を見る限り、非 UTF-8 HTML を Nokogiri::HTML(html).to_html して
doc.encoding がうまくいくかどうかテストするために入れたっぽい（若干改変してるが）
ある程度複雑な Shift_JIS の HTML が必要だったのだろう

604 ：デフォルトの名無しさん：2009/08/01(土) 19:34:42

あ、このへんね
ttp://github.com/tenderlove/nokogiri/commit/5ff00825309734341474350848dcaa268ee786b5
ttp://github.com/tenderlove/nokogiri/commit/b1a62250c2e15b93cb955b24a1c41a8467213d55

605 ：デフォルトの名無しさん：2009/08/01(土) 19:44:27

ねー、自分では作（れ）る気しないけど、あったら便利だなというライブラリってなんかある？

606 ：デフォルトの名無しさん：2009/08/01(土) 20:15:43

>>605
blade

607 ：デフォルトの名無しさん：2009/08/01(土) 20:37:49

>>605
・Win32APIの使いやすいラッパー
・pure ruby版Nokogiri
・pure rubyかつ強力な画像処理ライブラリ

ライブラリじゃないけど番外で
・RDEのような軽量開発環境＋クロスプラットフォーム＋安定
・GUIビルダー

608 ：デフォルトの名無しさん：2009/08/01(土) 21:41:11

せいぜいサムネールが作れてあとは縦横のサイズが取れるくらいの
画像処理ライブラリは欲しいなー。
RMagickはかさばりすぐる。

609 ：デフォルトの名無しさん：2009/08/01(土) 22:24:17

pureRuby厨うぜえ
超遅い部分をCで書き直して何が悪いんだよ

610 ：デフォルトの名無しさん：2009/08/01(土) 22:36:24

pureRuby厨分類
* 原理主義 (とにかくPureRubyこそ至上、MRI以外で困るから)
* 標準添付はよい(rootのない環境で困るから)

611 ：デフォルトの名無しさん：2009/08/01(土) 22:41:56

>>609
過剰反応うぜえ

612 ：デフォルトの名無しさん：2009/08/01(土) 22:49:07

REXMLがPure Rubyであの重さなわけだが・・・

613 ：デフォルトの名無しさん：2009/08/01(土) 22:55:42

>>610
「CGIで動かないと困る派」も追加で

614 ：デフォルトの名無しさん：2009/08/01(土) 23:28:34

nokogiriは素晴らしい

615 ：デフォルトの名無しさん：2009/08/01(土) 23:29:28

自演乙

616 ：デフォルトの名無しさん：2009/08/01(土) 23:31:12

だーれーのー
だーれーのー自ー演ー

>>613
「CじゃなくPureRubyで作りましたライブラリ」の動作速度でCGIが動いたら果てしなく困ると思うんだけどね
インストールさえできれば運用はどうでもいいのかしら

617 ：デフォルトの名無しさん：2009/08/01(土) 23:35:54

オバマ

618 ：デフォルトの名無しさん：2009/08/01(土) 23:36:07

pure rubyでも拡張ライブラリでもいいじゃない、使い分ければ

619 ：デフォルトの名無しさん：2009/08/01(土) 23:44:31

拡張をCで書く理由の8割くらいは「CGIとかで動作させたとき遅くてやってられないから」だと思うんだが

620 ：デフォルトの名無しさん：2009/08/01(土) 23:46:37

>>616
用途によってはpure rubyの速度で十分だし
そもそもCGIでは、たいていの場合pure ruby以外に選択肢がない

俺の経験から言えば
複雑な画像処理やファイル圧縮は厳しいが、JSON/YAMLのパースや文字コード変換程度なら特に問題はないなー
HTML（XML）のパースあたりになってくると微妙

621 ：デフォルトの名無しさん：2009/08/02(日) 00:22:23

>>619
Cの拡張ライブラリを入れることができるような環境であれば、そもそもCGI使わなくね？
今ではmod_rubyとかFastCGIとか色々あるんだし

622 ：デフォルトの名無しさん：2009/08/02(日) 00:45:51

「今では」、mod_rubyはありえんだろ

623 ：デフォルトの名無しさん：2009/08/02(日) 02:34:54

CじゃなくてもJavaで書き換えても爆速になるんじゃね？
>>556さんどうなんよ？

624 ：デフォルトの名無しさん：2009/08/02(日) 05:34:44

>>621
そうだねCで拡張書けるだけのCの知識があればRubyなんて使う必要ないよね全部Cで書くよね

625 ：デフォルトの名無しさん：2009/08/02(日) 07:51:52

速度が必要なところはCで、それ以外はもっと高級な言語でってのは普通のことだろ

626 ：デフォルトの名無しさん：2009/08/02(日) 08:59:22

>>624-625がどこにどう反論してるのか理解できない

627 ：デフォルトの名無しさん：2009/08/02(日) 11:14:10

遅いメソッドをプロファイラで割り出して、拡張ライブラリとしてCで書き直すって
よくやるんだけど、思った程速くならないんだよなぁ。
やっぱ rb_funcall とかしまくるくらいなら意味ないのかな？

628 ：デフォルトの名無しさん：2009/08/02(日) 11:48:16

Purerubyが遅いというのは甘え。どうせクソ設計のせい。
（性能が）足りぬ足りぬは工夫が足りぬってな。

629 ：デフォルトの名無しさん：2009/08/02(日) 12:02:12

すごいな、全世界のRubyユーザーが揃ってクソ設計してるなんて

…それって言語側に原因があるんじゃね？

630 ：デフォルトの名無しさん：2009/08/02(日) 12:07:25

nokogiriとREXMLの圧倒的な差

631 ：デフォルトの名無しさん：2009/08/02(日) 12:07:45

>>628
さすがにC言語と比較してそれはない

632 ：デフォルトの名無しさん：2009/08/02(日) 12:14:16

>>605
win32用の高速なcrc16計算ライブラリが欲しい。今すぐに！

633 ：デフォルトの名無しさん：2009/08/02(日) 13:06:46

.NET FrameworkにCRC32すら入ってなくて絶望した俺が通り過ぎます

634 ：デフォルトの名無しさん：2009/08/02(日) 13:28:11

>>632
Cでいいか？

635 ：デフォルトの名無しさん：2009/08/02(日) 13:55:02

rubyも、pure ruby界とC界の境界面で高いコストが掛かる実装なの？
頻繁にCで書いたメソッド呼ぶとマーシャリングで余計遅くなるとか？

636 ：デフォルトの名無しさん：2009/08/02(日) 14:03:54

Windowsを使ってるやつにCRCなんぞ不要。ファイルが壊れてたら
再送すればいいだけ。

637 ：デフォルトの名無しさん：2009/08/02(日) 14:10:40

つかMD5やSHA-1じゃなくあえてCRCが要求される場面って何？
速度的にCRCが爆速ってわけでもないのに

638 ：デフォルトの名無しさん：2009/08/02(日) 14:11:17

>>637
既存のファイルフォーマットなりプロトコルがCRC32を使っている場合

639 ：デフォルトの名無しさん：2009/08/02(日) 14:18:11

歴史的経緯って奴だな
新規でCRC32を使用することはなかろう

640 ：デフォルトの名無しさん：2009/08/02(日) 16:09:29

CRC32だったらZlib.crc32が使えるね。
CRC16だと自分で用意しないとダメだなぁ。

641 ：デフォルトの名無しさん：2009/08/02(日) 18:30:01

>>262-263 あたりのnokogiriの話。

どうもnokogiriのWindows版gemに同梱されてるDLLは
libXML2の公式サイトからリンクされてる
ttp://www.zlatkovic.com/libxml.en.html
のもののようなので、
ttp://www.zlatkovic.com/pub/libxml/iconv-1.9.2.win32.zip
のDLLの情報等を参考にしつつ、libiconvの1.13に
森山さんのところのパッチ
ttp://www2d.biglobe.ne.jp/~msyk/software/libiconv-1.13-ja-patch.html
をあてたものを
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っておきます。
ttp://www1.axfc.net/uploader/Sc/so/23793.zip

642 ：デフォルトの名無しさん：2009/08/02(日) 18:36:46

pureRubyじゃないときに困るのは一部のプラットフォームにしか対応してないとか
バイナリパッケージがない場合とかですかね。

もはやmswin32(というかActiveScriptRubyとOne-Click Installer)が
Rubyユーザの最大勢力なわけで、大抵そのあたりでもめるというか。

643 ：デフォルトの名無しさん：2009/08/02(日) 19:50:03

最大勢力の欲求が常に正しいとは限らないし、満たしてやる必要もない

644 ：デフォルトの名無しさん：2009/08/02(日) 20:00:54

と、思いつつ最終的に「満たすことになる」のが世の習いでもあり。

実際（別視点で見たときの）最大勢力であるRails勢の望みは
リリースエンジニアリング含めかなり呑むことになったわけで。

もちろん言語仕様的な部分とかでまつもとさんが一線を守るのは
悪くないけれども、じゃあこの点については実際のところどうなの、
という話になるわけで。

645 ：デフォルトの名無しさん：2009/08/02(日) 20:10:58

>>643
The Netが商用利用に解放された当時、そのころの細い回線を大事に
使っていた人たちのうちくちさがない人々は
「一般人にネットなど与えるな」などと言ったものでした

当時の旗振り役が答えて曰く
「そうなればいずれ彼らは自分たちでネットを生み出し今のネットにとって変わるだろう」
「もしそうであればそのとき君たちの居場所はあるだろうか?」
と

まあ実際その通りになったのですが

646 ：デフォルトの名無しさん：2009/08/02(日) 20:34:41

へー

自分たちでネットを生み出したんだ。そんな歴史初耳w

647 ：デフォルトの名無しさん：2009/08/02(日) 20:44:12

>>初心者スレの821
rb_block_tのproc見て、なかったらiseq->argc見れば変換はいらなくね？
とはいえそんなのはキモすぎて御免だが

648 ：デフォルトの名無しさん：2009/08/02(日) 21:33:52

>>646
無知ですねえ。
これだから自称古参は困るw

649 ：デフォルトの名無しさん：2009/08/02(日) 21:35:58

じいさんの昔話はレトロ板でやってくれ

650 ：デフォルトの名無しさん：2009/08/02(日) 23:55:32

>>632
>>640
ttp://www.zorc.breitbandkatze.de/crc.html ( http://www.zorc.breitbandkatze.de/crctester.c )
ttp://boost.cppll.jp/HEAD/libs/crc/crc.html

651 ：デフォルトの名無しさん：2009/08/03(月) 10:41:21

年寄りは今の時代についていけないからな。昔話するしか無い。
戦争は悲惨だから嫌だとか逝って競争することを放棄した年寄りが日本を駄目にした。気がつけば競争力無くて景気低迷。ちゃっかり競争が無いはずの非資本主義の支那に美味しい所を持っていかれてる。

ピュアルビーが遅いのって、ルビーインタラプタが遅いからだろ。
信者は、教祖の実装がゴミのせいで遅いと口が避けても言えないってだけじゃ。

652 ：デフォルトの名無しさん：2009/08/03(月) 10:45:38

ttp://jp.rubyist.net
みれない

653 ：デフォルトの名無しさん：2009/08/03(月) 10:57:44

>>651
http://hideyoshi.2ch.net/asia/

654 ：デフォルトの名無しさん：2009/08/03(月) 11:43:28

インタラプタについて語るスレになりまつた。

655 ：デフォルトの名無しさん：2009/08/03(月) 11:57:12

1.8のコードなんてもう読んでないからインタラプタとかよくわかんあい

656 ：デフォルトの名無しさん：2009/08/03(月) 12:25:25

>>651
さっさと核戦争やれ
まで読んだ

657 ：デフォルトの名無しさん：2009/08/03(月) 12:47:33

ルビーインドヒマラヤ

658 ：デフォルトの名無しさん：2009/08/03(月) 13:15:34

>>651
その種の文句は方々で言われてるだろ。
matzはコミット権を取り上げると脅される程度の扱いだぞ。

659 ：デフォルトの名無しさん：2009/08/03(月) 13:24:37

>>658
あんまりネタを引っ張ってると恥ずかしいよ
あれはあくまでテストとドキュメント書けって話だし

660 ：デフォルトの名無しさん：2009/08/03(月) 14:04:53

でもまあ「コードがドキュメントだ」的な発言は粉砕されてしまうようになったかな

661 ：デフォルトの名無しさん：2009/08/03(月) 14:11:11

実際にマニュアル文書こうとするとわかるが、Ruby スクリプト部分に関してはコード読ませたほうが早い
それこそ「変数 i に整数 10 を代入する」レベルのことにしかならなかったり

必要なのは、個々のメソッド動作の詳説ではなく、網羅的なメソッド動作一覧だったりする

662 ：デフォルトの名無しさん：2009/08/03(月) 15:16:33

スクリプトの説明とマニュアルは違う

コードの動作を知らせるのならそりゃコード読ませたほうが早いが
コードの動作が何を意図しているのかを明確にするために
ドキュメントを書くべき

663 ：デフォルトの名無しさん：2009/08/03(月) 15:18:15

ドキュメントとマニュアルは開発者が書かなくてもよい
別の人が書いてもよい

664 ：デフォルトの名無しさん：2009/08/03(月) 15:32:53

ドキュメントやマニュアルとはそもそもなんぞやという話に

665 ：デフォルトの名無しさん：2009/08/03(月) 18:52:42

ドキュメントはChangeLogとかも含むかな

666 ：デフォルトの名無しさん：2009/08/04(火) 00:06:50

作った香具師しか分からない様な糞コードだからドキュメントが必要。
cgi.rbなんて典型だろ。

667 ：デフォルトの名無しさん：2009/08/04(火) 00:09:35

きちんとしたドキュメントがあるのとないのとで、使い方から潜在的なバグの発見まで
どれだけ敷居が低くなるのかってことはあるはずなんだが。
そもそも人に使って貰うことを前提に公開・配布してるんと違うんかと。

668 ：デフォルトの名無しさん：2009/08/04(火) 00:55:56

cgi.rbが糞コードってのは公認なの？
俺がアホだから解りづらいのか、糞コードだから解りづらいのか、
どっちなのか悩んだ事があったんだが。

669 ：デフォルトの名無しさん：2009/08/04(火) 01:11:55

PerlのCGIモジュールの再実装だから、当然・・・。

670 ：デフォルトの名無しさん：2009/08/04(火) 01:58:15

あれは「これをもとにブラッシュアップする」という予定をすっ飛ばされたライブラリだから
cgi.rb 自体が悪いというよりは、それこそリリースエンジニアリングが悪い

671 ：デフォルトの名無しさん：2009/08/04(火) 02:15:08

そもそも「CGI汎用対応ライブラリ」は実装が汚くなる傾向にある

バージョン 0.2 くらいでは非常に理想的なコード進行なんだが、
バージョン 0.95 になると特殊条件割り込みやら外部バグ対応やらでぐちゃぐちゃに

672 ：デフォルトの名無しさん：2009/08/04(火) 02:37:35

ライブラリの中がある程度汚くなるのは仕方ない分野もあるってことかな
その分、APIの統一やらドキュメントの充実やらで対応するのが常道だろうけど
ソース嫁って意見はその辺はどう考えてるんだろうか
まさかコメントあるからおｋってことでも無かろうが

673 ：デフォルトの名無しさん：2009/08/04(火) 04:36:26

できれば標準ライブラリは一番綺麗なお手本でいてほしい。
その言語処理系でなにかしようとするなら、まず標準ライブラリを参考にするし。

ただ、「これをもとにブラッシュアップ」とか言ってたらオープンソースじゃ
一生リリースできないからね。何もないよりは、はやリリしょちゅリリのほうがいいよ。

ここでグダグダ言ってるよりか何か書いてパッチでも送りつけるorパッチ袋に
蓄積するというほうが現実的なんではないかな。あ、俺はやらないけどw
そんな暇あったら自分の仕事するしw

674 ：デフォルトの名無しさん：2009/08/04(火) 06:07:19

ちなみに、cgi.rbをブラッシュアップするぜと言ってメンテナになられた奇特な方がxibbarさんなので、
みなさん意見とか言ってあげてください

675 ：デフォルトの名無しさん：2009/08/04(火) 06:30:59

え、何が楽しいのとか馬鹿じゃねーのとか他のことやったらとかそういう意見でもいい？

676 ：デフォルトの名無しさん：2009/08/04(火) 06:35:53

WEBrickにセッション機能つけてcgi.rb捨てようぜ

677 ：デフォルトの名無しさん：2009/08/04(火) 08:23:39

むしろRackを標準にしてcgi.rbを捨てるのがいいんじゃね

あと、確か一時期cgialtに置き換えようって動きもあったよね
あれどうなったのかな

678 ：デフォルトの名無しさん：2009/08/04(火) 08:26:23

Rack は CGI 環境での動作テストをせずにガンガンリリースしまくったという負の実績が…

679 ：デフォルトの名無しさん：2009/08/04(火) 08:28:24

>>651
http://tsushima.2ch.net/test/read.cgi/newsplus/1249297928/

680 ：デフォルトの名無しさん：2009/08/04(火) 08:48:59

>>678
それで1.0.0でもCGIが動かないという恐るべき状況になったのか

681 ：デフォルトの名無しさん：2009/08/04(火) 10:07:18

>>677
Ruby本体では、年1リリースでも支障がない程度に安定していることという暗黙の前提があるので、
Rackが入るにはもうしばらくかかるんじゃないかな。
たまに話が出るFFIも同様の理由で当分はない。

CGIAltにはすでに置き換わってるよ。
気づかなかったとしたらそれはxibbarさんが慎重にテストしながら置き換えた成果だね。

682 ：デフォルトの名無しさん：2009/08/04(火) 10:13:58

>>675
> え、何が楽しいのとか馬鹿じゃねーのとか他のことやったらとかそういう意見でもいい？
同旨の事は言った気がする（ぉ

683 ：デフォルトの名無しさん：2009/08/04(火) 10:29:43

ライブラリのソースを読んだ知見を元に何でドキュメントを書かないの？

684 ：デフォルトの名無しさん：2009/08/04(火) 10:39:36

ソースを読む才能とドキュメントを書く才能って別なんだよね。
リファレンスマニュアルならすでにあるし

685 ：デフォルトの名無しさん：2009/08/04(火) 10:43:36

それが理解できず開発者にドキュメントを強いる衆愚

686 ：デフォルトの名無しさん：2009/08/04(火) 11:16:57

引き篭もりはこれだから困る（）笑

現実の世界見てみろよ！
製作者が公演したり解説したり本書いたりするのが当たり前だから！
そして微妙な空気に支配される会場！がっかりが埋め尽くす書評！
無下にするわけにもハブるわけにもいかず仕方なく「スーパーバイザー」とかよくわからん横文字で濁されるお茶！

687 ：デフォルトの名無しさん：2009/08/04(火) 11:21:03

ああ、監修：ま何某ってそういう…

688 ：デフォルトの名無しさん：2009/08/04(火) 11:21:50

>>686
無知、乙

689 ：デフォルトの名無しさん：2009/08/04(火) 11:30:20

そういう役割分担というか、専門技能へのドライな眼差しは、
日本人が苦手としているところかもね。
スポーツでも、日本文化に古くから染み込みすぎて旧態依然としている分野（野球、相撲）ほど、
プレーヤーとトレーナー&マネージャーをごっちゃにするし。

690 ：デフォルトの名無しさん：2009/08/04(火) 11:30:34

>>686
関係者かなんか知らんけどあんな人無理に壇上で喋らせなくてもいいのに、と思うことはなくもない
せめて巷の体育の先生くらいには話のできる人がフォローすべき
インタビュー形式とか色々あんじゃんね
Ruby関係ないな

691 ：デフォルトの名無しさん：2009/08/04(火) 11:48:36

いや、あの公演、当日までスライドできて無くてアレしゃべってるんだぜ
すごい才能だと思わないか
いや、別にほめられた事じゃないけどさ

692 ：デフォルトの名無しさん：2009/08/04(火) 12:35:54

もちおみたいにオープンソースの理解も足りないんだろうな
あと、多くは開発者以外がドキュメントを書いている事実も。
Ruby 以外の言語も知っておくのは、そういう意味でも重要。

693 ：デフォルトの名無しさん：2009/08/04(火) 12:37:19

>>688=>>692

694 ：デフォルトの名無しさん：2009/08/04(火) 13:55:42

>>681
>CGIAltにはすでに置き換わってるよ。
ダウト

695 ：sage：2009/08/04(火) 15:11:48

>694
1.8系しか見てないのかな

696 ：デフォルトの名無しさん：2009/08/04(火) 15:17:46

>>694
おおう、たしかにCGIAltそのものではなかった
http://d.hatena.ne.jp/xibbar/20090124

697 ：デフォルトの名無しさん：2009/08/06(木) 22:06:18

IronRuby 0.9

698 ：デフォルトの名無しさん：2009/08/06(木) 23:01:11

IronRubyとJRuby、なぜ差がついたか… 資金、開発環境の違い・・・

699 ：デフォルトの名無しさん：2009/08/06(木) 23:24:23

>>698
どっちがいいの？

700 ：デフォルトの名無しさん：2009/08/06(木) 23:39:00

どっちも駄目

まだ

きちんと一定の形に完成しないのなら意味がない

701 ：デフォルトの名無しさん：2009/08/06(木) 23:41:59

JRubyは完成したとして何に使うのかがよくわからない
IronRubyはWin環境でのライブラリ不足を一挙に解決してくれるからな

702 ：デフォルトの名無しさん：2009/08/07(金) 00:01:12

ふと一行78文字ルールと戦うIronPythonデベロッパの姿が脳裏に浮かんだ

703 ：デフォルトの名無しさん：2009/08/07(金) 00:26:51

JRubyだってJavaのライブラリ使えるのが強みだろうさ
あとJVMが動く場所なら動くことと、JVMが速くなりゃJRubyも速くなること

704 ：デフォルトの名無しさん：2009/08/07(金) 04:03:18

1.9.1の最新版のmswin32のバイナリは出ないのだろうか・・・

705 ：デフォルトの名無しさん：2009/08/07(金) 08:33:10

>>700
「きちんと一定の形」についてもう少しkwsk

706 ：デフォルトの名無しさん：2009/08/07(金) 08:47:11

>>704
ftp://ftp.ruby-lang.org/pub/ruby/binaries/mswin32/
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/46231

なぜusaさんのページで出てないのかは謎

707 ：デフォルトの名無しさん：2009/08/07(金) 11:50:58

jrubyはもう駄目だろ Sunにさえ見放された
IronRubyは世界標準のWindowsだし、世界最強IT会社のMS製だし・・・

708 ：デフォルトの名無しさん：2009/08/07(金) 12:07:19

マイクロソフトが手を出せば成功するというのなら世の中はとっくに

709 ：デフォルトの名無しさん：2009/08/07(金) 12:26:30

Ruby の今後について、マーケティング用語「キャズム」を紹介する
ttp://www.mitsue.co.jp/case/glossary/m_023.html
一般的にテクノロジーのライフサイクルはベル型の標準偏差のグラフによって示され、
その各段階でターゲットとすべき顧客として、イノベーター、アーリー・アドプ
ター、アーリー・マジョリティ、レイト・マジョリティ、ラガードといった顧客セグ
メントが行なわれます。通常、この顧客セグメントによって、異なるマーケティング
施策を行いながら、徐々に新しいテクノロジーの顧客層を広げていくことが推奨され
ます。しかし、米のマーケティング・コンサルタントであるジェフリー・ムーア氏が、
同名の著書によって、明らかにしたのは、イノベーターとアーリー・アドプター
で構成される初期市場と、アーリー・マジョリティやレイト・マジョリティによって
構成されるメジャー市場のあいだには、容易には越えがたい「キャズム（深いミ
ゾ）」あるということでした。顧客セグメントの違いによって生み出される、この
キャズムを超えなくては、新しい商品はメジャー市場でブレイクすることなく、規模
の小さな初期市場のなかでやがては消えていく運命となります。同著が、10年間にわ
たって米国ハイテク業界のバイブルとされたように、特にテクノロジーの進歩の激し
い業界においては、強く意識することが重要なマーケティング理論です。

以下は、マーケティングの視点で、Twitter の普及を分析
Twitter の快進撃がとまった!?～スローダウンの要因を分析する
ttp://japan.internet.com/column/busnews/20090709/8.html

710 ：デフォルトの名無しさん：2009/08/07(金) 12:35:14

ふだんは Java と Ruby を両方いじっている者だが
(Java 系のエンジニアだが、さいきん Rails も覚えた)

Java のプロジェクト内ライブラリを叩く運用ツール(半使い捨て)を、
# たとえば在庫一覧をファイルに出力するツールなど
いまは Java のプログラムでつくっているが、
これを JRuby でやるようにしたら、もっと手軽に作れないかなと思っている。

JRuby は、マルチスレッドプログラミングするなら Ruby 1.9 系よりも速いんじゃなかったっけ？
このスレだかどこかで読んだような

711 ：デフォルトの名無しさん：2009/08/07(金) 12:51:12

>710
そういうのは、Scalaでやった方がいいと思う。

712 ：デフォルトの名無しさん：2009/08/07(金) 13:12:29

>>710
Javaなら一応Groovyとかもあるかな

arton氏が似たようなシチュエーションでrake使って
自動化とか効率化とかやってたはず

713 ：710：2009/08/07(金) 13:17:10

>>712
Groovy は少しかじったけど、なんかいまいち。
Ruby のほうが見やすいし、Ruby / Groovy でできないところは Java で書く。
Groovy は Java しか出来ない人のスクリプト言語って感じだけど、Ruby 本物を覚えてしまった今、
いまいち中途半端だなあと感じる。

>>711
Scala でも使い捨てスクリプトをちゃちゃっと作れるのかな。

714 ：デフォルトの名無しさん：2009/08/07(金) 14:24:50

JRubyがもう少し起動早くなったらGUIが気持ちよくかけるかもしれない

715 ：デフォルトの名無しさん：2009/08/07(金) 17:19:04

>>713
そんなことない。
Groovyは最初からJavaと連携できるよう考慮されているから、Javaもよく使うならJRubyよりGroovyのほうがいい。
JRubyはあくまでRubyをJVMで使いたい人向け。

716 ：710：2009/08/07(金) 17:38:54

>>715
なるほど。
どうやら自分は、まだ Groovy への理解が足りないようだ。もうちょっと勉強してみるよ。
でも、るび厨になってしまったので、Ruby や JRuby いじっているほうが楽しいんだけどね。

717 ：デフォルトの名無しさん：2009/08/07(金) 21:53:14

あとGroovyは一時はJavaSDKに標準添付の話まであったのに
そのあと大きな動きがなくてプロジェクトが死んじゃってるんじゃねえの、って状態なのも難点かなあ

718 ：デフォルトの名無しさん：2009/08/07(金) 22:22:20

Groovyはコレの24p以降のイメージが強烈すぎた
ttp://kakutani.com/articles/LLW2004-LanguageUpdate-Groovy.live.pdf

719 ：デフォルトの名無しさん：2009/08/07(金) 23:21:26

おまえらのせいでGroovyに興味が湧いてきた

720 ：デフォルトの名無しさん：2009/08/07(金) 23:43:45

>718
なんだこれｗｗｗｗｗｗｗ

721 ：デフォルトの名無しさん：2009/08/07(金) 23:49:51

なついなあライブでみたよ

722 ：デフォルトの名無しさん：2009/08/07(金) 23:53:53

>>718
無駄に力作過ぎるが、全体を通してみてこれで使ってみたくなるか？という素朴な疑問
公平な紹介ってなんだろうけど

723 ：デフォルトの名無しさん：2009/08/08(土) 09:25:45

>>718
ネタ帳かとおもたwwwwwwww

724 ：デフォルトの名無しさん：2009/08/08(土) 09:28:03

弱点
● 機能セットがすべて出揃っていない
? 匿名インナークラスが未サポート（Groovy-1.1までに対応?)
? モダンなIDEでのサポートが不十分(Eclipse, IntelliJ...)
● 実行速度が遅い
? 対Java比: 20～90%
● デバッギング・ヘル!
? パーサが未成熟: わけのわからんエラーメッセージ

wwwwww

725 ：デフォルトの名無しさん：2009/08/08(土) 10:20:13

>>724
それ、いつのこと？現時点での話じゃないよね

726 ：デフォルトの名無しさん：2009/08/08(土) 11:37:41

>>725
>>718のPDFを見れば書いてあるよな

727 ：デフォルトの名無しさん：2009/08/08(土) 11:53:34

Ruby 初心者スレッド Part 30
ttp://pc12.2ch.net/test/read.cgi/tech/1249687283/
初心者スレが立ちました

アンチスレは落ちたままです
最終の遣り取りは以下の通り

> 979 名前：デフォルトの名無しさん　[sage]　投稿日：2009/08/06(木) 19:50:29
> 　　Ruby ってメモリ馬鹿食いするよね？
>
> 980 名前：デフォルトの名無しさん　[sage]　投稿日：2009/08/06(木) 19:57:59
> 　　まあ、そこそこには
> 　　省メモリで動作することが重要なのならRubyは使ってはいけない

728 ：デフォルトの名無しさん：2009/08/08(土) 12:41:08

>>726
>>>718のPDFを見れば書いてあるよな

それ、2004年の資料だよね。だから>>724は現時点での話じゃないよね。
おわかり？

729 ：デフォルトの名無しさん：2009/08/08(土) 12:51:02

別にいいけどおまえの言うことを
必死でくみ取ってくれる存在なんて両親くらいだぞ

730 ：デフォルトの名無しさん：2009/08/08(土) 13:14:14

Rubyの会のサイトって死んでるの？
解散した訳じゃないよね？
http://jp.rubyist.net/

731 ：デフォルトの名無しさん：2009/08/08(土) 13:35:53

>730

最近サーバの調子が悪いらしい

732 ：デフォルトの名無しさん：2009/08/08(土) 13:39:03

PJの社長みたいに金余ってる人がスポンサーにつかないものか

733 ：デフォルトの名無しさん：2009/08/08(土) 13:50:15

最近と言っても、ここ数日の話なので仕方ないと思われる。

734 ：デフォルトの名無しさん：2009/08/08(土) 17:07:25

1.8の方のDLってひょっとして可変長引数扱えないのかな。

ruby-ffiは出来るみたいだからそっちでごまかすかのう。

735 ：デフォルトの名無しさん：2009/08/08(土) 20:02:51

>>732
Ruby 界隈でイケメンはいないだろ

736 ：デフォルトの名無しさん：2009/08/08(土) 20:44:54

アンチスレも消えてすっきりしたな

737 ：デフォルトの名無しさん：2009/08/08(土) 23:09:44

>735
_why はイケメン。

738 ：デフォルトの名無しさん：2009/08/08(土) 23:50:23

これって既出ですかね？

Ruby1.9.1、Python3.1、Java1.6.0の実行速度比較
http://www.mwsoft.jp/programming/other/compare_speed_ruby_python_java.html

1.8は遅かったけど1.9はかなり速くなったと聞いてたので
そろそろRubyをしっかり勉強するのもありかなと思ってたんですが
この結果を見て愕然としました
何故にこれほど遅いんでしょう…
もう高速化の手段は残ってないんでしょうか…

739 ：デフォルトの名無しさん：2009/08/08(土) 23:59:25

WindowsでRubyって・・・

740 ：デフォルトの名無しさん：2009/08/09(日) 00:17:54

>>738
高速化技法はまだ全然試されていないからまだまだ伸び代はある。

Pythonも高速化計画が持ち上がってたはずだし。

741 ：デフォルトの名無しさん：2009/08/09(日) 00:18:17

そういえばRubyが遅い遅いとは言われてるけど
なんで（少なくともベンチマーク上では）遅いのか、その理由がよくわからない

1.9.1からYARVが入って、他の言語と同じバイトコンパイルになったはずだし
Pythonあたりと柔軟性で極端な違いがあるとも思えないし

742 ：デフォルトの名無しさん：2009/08/09(日) 00:19:57

>>738
きっきっと、新しいバージョンだから遅いいんだよ
最適化された・・・バージョンアナら・・・ぼぼろ負けはしないよ

>>739
LinuxにはPython入ってるから、Windowsで・・・

743 ：デフォルトの名無しさん：2009/08/09(日) 00:27:05

正直、じゃんごの日本語リファレンスとかもうちょっと充実してきたら
Pythonに移ってもいいかなって思ってる

744 ：デフォルトの名無しさん：2009/08/09(日) 00:31:09

俺は日本語リファレンスが充実しても、Pythonには行かないなー
Rubyが使いやすすぎて、ちょっとやそっとの速度差で止める気にはならない
どうしても速度が気になるなら拡張ライブラリがあるし

745 ：デフォルトの名無しさん：2009/08/09(日) 00:35:37

IronRubyによってMSが10倍速にしてくれるから気にするな
Linuxは知らん

746 ：デフォルトの名無しさん：2009/08/09(日) 00:36:34

>>745
その時には素敵な拡張文法がてんこ盛りだったりして

747 ：デフォルトの名無しさん：2009/08/09(日) 01:20:32

JRubyでいいじゃんはやいじゃん

748 ：デフォルトの名無しさん：2009/08/09(日) 01:46:45

とりあえずRubyがWindows上で遅い、特に一定の条件が揃うと妙に遅いというのは前から言われてる
あと、usa版バイナリはVC6でコンパイルしているので最適化が甘い
ので、まずはコンパイラを揃えてテストするべき

749 ：デフォルトの名無しさん：2009/08/09(日) 01:48:48

ということは、mingw版の方が速い可能性があるってことなのか

750 ：デフォルトの名無しさん：2009/08/09(日) 01:52:45

というか、Linuxサーバー上で運用されることが実際には多いんだから
Linuxでテストしないと意味がないと思うんだが・・・
Windowsサーバー使えるような企業やハイソサエティはRubyなんて使わんで
ASP.NET使うだろｊｋ・・・

751 ：デフォルトの名無しさん：2009/08/09(日) 07:46:33

> ということは、mingw版の方が速い可能性があるってことなのか
まぁ、それはあるけど、素直にVC9を使うのが楽だと思うよ

> Windowsサーバー使えるような企業やハイソサエティはRubyなんて使わんで
> ASP.NET使うだろｊｋ・・・
IronRubyをテストしてあげて！

752 ：デフォルトの名無しさん：2009/08/09(日) 09:02:21

>>751
またそんないばらの道を...

というかmingw32のほうがVC(9含めて)よりはやいというのは、以前からわかってる。

753 ：デフォルトの名無しさん：2009/08/09(日) 16:41:58

Windowsならgcc -O3で野良だろJK

754 ：デフォルトの名無しさん：2009/08/09(日) 16:46:52

Ruby/Tkさえコンパイルできるようになれば、すぐにmingw版に移るんだが

755 ：デフォルトの名無しさん：2009/08/09(日) 17:00:11

>>754
普通にできてるが

756 ：754：2009/08/09(日) 17:12:14

>>755
え、本当？

俺の環境では ruby-list:46093 と同じ問題でコンパイルできない・・・
何が問題なのかさっぱりだ
配布バイナリがあればそっちを使うんだけど、更新止まってるみたいだし

757 ：デフォルトの名無しさん：2009/08/09(日) 17:31:30

>>753
GCの関係で、最適化かけすぎると
不味いんじゃなかったっけ？

758 ：デフォルトの名無しさん：2009/08/09(日) 17:52:37

ソースコード完全解説には「-O2まで」と載ってるな
ttp://i.loveruby.net/ja/rhg/cd/build.html （「最適化のヒント」の項）

759 ：デフォルトの名無しさん：2009/08/09(日) 18:45:58

>>758
むしろ-O3より-O2の方がコンパイルに時間がかかったって話も聞くけどな

760 ：デフォルトの名無しさん：2009/08/09(日) 19:01:57

The Computer Language Benchmarks Game
http://shootout.alioth.debian.org/index.php

761 ：デフォルトの名無しさん：2009/08/09(日) 19:57:53

>>758
いつの時代の本だよ

762 ：デフォルトの名無しさん：2009/08/09(日) 21:22:36

いやgccの-O2と-O3の差とか、当時とそんなに変わってないし、
Rubyもevalこそ入れ替わったけど、GCは基本同じだし。

763 ：デフォルトの名無しさん：2009/08/09(日) 22:10:26

RHG1.9版出せよ

764 ：デフォルトの名無しさん：2009/08/09(日) 22:18:27

OneClickRubyInstaller の次期バージョンになる予定のRubyInstallerは、
mingw版です。ダウンロードできるけど、まだプレビュー版です。
ttp://rubyinstaller.org/downloads/

みんなでテストして、安定すれば問題解決じゃない？

1.8系はmingwにするだけで倍以上早くなるみたいだし。
ttp://antoniocangiano.com/2009/08/04/a-faster-ruby-on-windows-is-possible/

765 ：755：2009/08/10(月) 00:15:17

>>756
俺もstubはダメだったんで非stubで使ってる。
Tcl/Tk 8.5 以降できなくなったような気がする。
ちなみにActiveTcljは使ったこと無い。いつもソースからビルドしてる。

766 ：デフォルトの名無しさん：2009/08/10(月) 03:28:30

>>762
> いやgccの-O2と-O3の差とか、当時とそんなに変わってないし、
ソースだせソース

767 ：デフォルトの名無しさん：2009/08/10(月) 07:13:49

最近は-O3でも動くらしい（ソースはIRCでの中田さんの発言

768 ：デフォルトの名無しさん：2009/08/10(月) 08:37:56

もう1年以上-O3のRuby(MinGWとlinux)使ってるけど
特に問題になったことはないなあ

769 ：デフォルトの名無しさん：2009/08/10(月) 20:17:04

少なくとも写真はこっちが勝ちだな

「変わっていかなければ」。日本Rubyの会会長の葛藤－＠IT自分戦略研究所
ttp://jibun.atmarkit.co.jp/ljibun01/rensai/leader/27/01.html

770 ：デフォルトの名無しさん：2009/08/10(月) 20:23:33

世界にはばたく日本のRuby（笑）から（笑）を取ってもいい頃合の状況なのに、
実際の中の人の活動は状況に比べて芳しくないんだよね

771 ：デフォルトの名無しさん：2009/08/10(月) 20:50:57

Javaの解説やドキュメントを書くのは楽しい
なぜなら、足りない部分を補填するという自覚がもてるからだ
Rubyの解説やドキュメントを書くのは楽しくない
なぜなら、余計なものを重複して書いてる気分になるからだ

Rubyのスクリプトコードがもうちょっと読みにくかったら
ドキュメンテーションへのインセンティブになると思う

772 ：デフォルトの名無しさん：2009/08/10(月) 23:57:13

> Javaの解説やドキュメントを書くのは楽しい
奇特な性癖の持ち主発見

773 ：デフォルトの名無しさん：2009/08/11(火) 01:02:30

内容から察するに、わざわざツッコミ入れなくてもそういう意味だと思うぞ
「Rubyに比べてJavaのコードは解りにくいから、むしろドキュメント書くのが楽しくなる」という内容のようだから

774 ：デフォルトの名無しさん：2009/08/11(火) 01:22:03

実際にはJavaでもろくに書いてないんだろうけどな

775 ：デフォルトの名無しさん：2009/08/11(火) 01:25:32

分かりきったことをあらためて書くことほどつまらないことはないので
気持ちはわからなくもない

776 ：デフォルトの名無しさん：2009/08/11(火) 01:29:55

成程>>769での懸念も尤もだな
よっぽどJavaの4文字に負い目があるらしい

777 ：デフォルトの名無しさん：2009/08/11(火) 08:39:14

メッセージ伝達手段としての例外って使わないほうがいい？
1.9ではそもそも遅いとか聞くし

778 ：デフォルトの名無しさん：2009/08/11(火) 09:43:54

>>777
例外は例外なんだから例外的なことが起きた時にだけ使うべきだろう。

779 ：デフォルトの名無しさん：2009/08/11(火) 10:00:13

>>778
正論

大域脱出だったら catch と throw でいいんじゃないの？

780 ：デフォルトの名無しさん：2009/08/11(火) 11:10:02

Rubyでのthrow-catchはbegin-raiseとどう使い分けるの？
ふつうに例外処理があるのになんでcatch-throwがあるの？

初心者の素朴な疑問。

781 ：デフォルトの名無しさん：2009/08/11(火) 11:22:56

>>780
779が書いたように、throw～catchは大域脱出機構。
例外処理機構じゃない。

782 ：デフォルトの名無しさん：2009/08/11(火) 11:36:29

>>777
基本的には使うべきでない

ただしメッセージの種類によっては、判定が微妙なこともある
例：net/http.rb や open-uri.rb のHTTP例外

783 ：デフォルトの名無しさん：2009/08/11(火) 11:41:53

elseでのreturnは例外送出と根源的には同質
キャッチするかそのままにするかの違いでしかない

784 ：デフォルトの名無しさん：2009/08/11(火) 12:31:49

>>779
ライブラリが「このメソッドを呼ぶ時はcatchで括ってください」とか言ってきたらイヤだぞｗ

785 ：デフォルトの名無しさん：2009/08/11(火) 12:38:26

PStore#transactionとか

786 ：デフォルトの名無しさん：2009/08/11(火) 12:50:53

>>785
コード見て理解できた、指摘thx

787 ：デフォルトの名無しさん：2009/08/11(火) 15:05:47

>>785
理解できないので解説おねがい

788 ：デフォルトの名無しさん：2009/08/11(火) 15:07:48

>>784
検索メソッドを中断したらabort投げられるなんてのもないでもない

789 ：デフォルトの名無しさん：2009/08/11(火) 15:08:03

PStoreというクラスのインスタンスメソッドtransactionという意味

790 ：デフォルトの名無しさん：2009/08/11(火) 15:32:35

python の __getattr__ (属性へのアクセスのフック)のような事を ruby で行いたいのだがどうやれば良い？
method_missing ならぬ attr_missing みたいなメソッドがあれば良いんだけど発見できなかった。

791 ：デフォルトの名無しさん：2009/08/11(火) 15:49:05

できません

「インスタンス変数へのアクセスは全員アクセサメソッド使え」
とマニュアルにでっかい字で書いておくというのはどう

792 ：デフォルトの名無しさん：2009/08/11(火) 16:31:01

>>791
ｔｈｘ。
俺が見つけられなかっただけで、rubyでも絶対出来る方法があるだろーと思っていただけに意外でした。

793 ：デフォルトの名無しさん：2009/08/11(火) 18:24:41

>>789
だれもそんなこときいてねー！！
例外やcatch-throwの話しているときになぜ
>PStore#transactionとか
がでてきたのか（たとえばPStore#transactionがcatch-throwを使ってるとか）を聞いてるんだけど。

これが空気読めない理系どものコミュニケーション能力か！

794 ：デフォルトの名無しさん：2009/08/11(火) 18:32:49

>>793
そういう君こそ >>789 が言外に込めた意味を汲み取るべきでは？
ちなみに件のコードは見た？

795 ：デフォルトの名無しさん：2009/08/11(火) 19:35:00

＞（たとえばPStore#transactionがcatch-throwを使ってるとか）を聞いてるんだけど

見てたらこんなこと言わないか、一年ROMれのレベル

796 ：デフォルトの名無しさん：2009/08/11(火) 20:26:54

そうか、コールバック（イベント）メソッドという手もあったな

797 ：デフォルトの名無しさん：2009/08/11(火) 23:46:42

RubyやPythonの例外の使われ方を考えると
例外を例外的な状況だけで使えというのは
Java独自の風習じゃないかと思えてくる。

798 ：デフォルトの名無しさん：2009/08/11(火) 23:51:55

ジャヴァの例外周りの仕様は明らかにウンコ
C++の<< >>なIO stream並にフォロワーが出てこない

799 ：デフォルトの名無しさん：2009/08/12(水) 00:24:07

C++の例外はうんこ以前に普通に使えないという代物だからなあ
うんこはまだ食べられるだけマシだろ

800 ：デフォルトの名無しさん：2009/08/12(水) 04:42:59

それは例外ではなくただのエラーだと突っ込みたくなることが何度か

801 ：デフォルトの名無しさん：2009/08/12(水) 07:07:10

例外という日本語に引っ張られてるっぽい人は時々見る

802 ：デフォルトの名無しさん：2009/08/12(水) 07:20:25

>>792
trace的なものはあった気がするがすさまじく遅いから常用不可だった記憶

803 ：デフォルトの名無しさん：2009/08/12(水) 09:30:11

>>801
exception だとニュアンスがちがうのか？

804 ：デフォルトの名無しさん：2009/08/12(水) 09:38:30

「予期しないこと」ぐらいのニュアンスかな

805 ：デフォルトの名無しさん：2009/08/12(水) 09:41:00

よく知らんのだが、Lispのコンディションはもうちょっと積極的に
制御に組み込まれるんだろうか

806 ：デフォルトの名無しさん：2009/08/12(水) 09:45:43

>>801
例外なんて相対的なものだからね
ある人の例外は別の人にとって例外でなかったりする

807 ：デフォルトの名無しさん：2009/08/12(水) 09:58:03

OCamlの例外は積極的に制御機構として使われているね。
ループをbreakするときも例外とか。
よく知らんけど。

808 ：デフォルトの名無しさん：2009/08/12(水) 10:17:12

そもそもRubyの例外クラスには
StandardErrorなんてのが普通にあるんだし
それを考えても、エラーと例外をはっきり分ける意味はないと思う

809 ：デフォルトの名無しさん：2009/08/12(水) 10:36:09

例外って、実行時エラーに捕捉機能が備わっただけのような気もするな。

810 ：デフォルトの名無しさん：2009/08/12(水) 11:03:01

丸投げ機構

811 ：デフォルトの名無しさん：2009/08/12(水) 11:38:01

本スレに関係ない話題の隔離機構

812 ：デフォルトの名無しさん：2009/08/12(水) 13:01:02

むしろ本スレが隔離機構

813 ：デフォルトの名無しさん：2009/08/12(水) 13:13:33

隔離機構と薄力粉って似てるよね

814 ：デフォルトの名無しさん：2009/08/12(水) 13:20:53

隔離機構とカクリコンって似てるよね

815 ：デフォルトの名無しさん：2009/08/12(水) 13:24:16

∴ 薄力粉とカクリコンって似てるよね

816 ：デフォルトの名無しさん：2009/08/12(水) 13:39:36

>>790
method_missing 使え
Rubyはメソッドとか属性とかプロパティとか区別しない。

817 ：デフォルトの名無しさん：2009/08/12(水) 13:45:07

>>816
てゆか「メソッドしかない」んだけどね、厳密には

818 ：デフォルトの名無しさん：2009/08/12(水) 15:16:10

なんでこういう布教スレばっかり立てるん？

魁け！ Ruby 1.9.X
http://pc12.2ch.net/test/read.cgi/tech/1201603546/

819 ：デフォルトの名無しさん：2009/08/12(水) 16:17:53

>>818
何で今さら？
かなり前からあるぞそのスレw

820 ：デフォルトの名無しさん：2009/08/12(水) 21:09:26

MLの中にたこ焼き仮面がどうやらっていうメールがあって
何事かと思ったw

821 ：デフォルトの名無しさん：2009/08/12(水) 21:36:06

>>820
何で今さら？
かなり前からあれだぞそのカレw

822 ：デフォルトの名無しさん：2009/08/12(水) 21:56:32

>>821
そうだったのかw
ほとんどタイトルしか見ないからな

823 ：デフォルトの名無しさん：2009/08/13(木) 09:55:38

WEBrickのパースユーティリティって特定条件のパース遣り残しとか残ってる？
信用して丸投げしていい？

824 ：デフォルトの名無しさん：2009/08/13(木) 11:35:32

全く同じようなメソッドが大量に再発明されて氾濫してる現状からお察しください

825 ：デフォルトの名無しさん：2009/08/13(木) 11:51:36

やっぱり HTML とか HTTP とかの軽量クラスは作るべきだっただろうか
require 'cgi' が重いから嫌われてるんだよね escapeHTML

826 ：デフォルトの名無しさん：2009/08/13(木) 11:58:06

>>823
1.9でマルチバイト通さなかったことを誰も気づかなかった時点でお葬式

827 ：デフォルトの名無しさん：2009/08/13(木) 12:06:59

あのへんは、コードを読み解こうとしてRFCとか参照しようとするとわかるが、そもそも頭に入らないぞ
仕様読んでる時点で脳内スタックが溢れるという体験を久しぶりにした
「…このままでいいや」と呟いた俺

828 ：デフォルトの名無しさん：2009/08/13(木) 12:14:41

Railsさんはどうしてるのかなあ
どっかのライブラリに仕様を加味しつつ現実的な動作のメソッドがごそっと入ってそうだが

829 ：デフォルトの名無しさん：2009/08/13(木) 12:23:40

>>828
h と u については有名
ERB::Util の中に入ってる

irb> require 'erb'
irb> include ERB::Util
irb> p h('<html>')
"<html>"
irb> p u('ABCDE!,.[]123')
"ABCDE%21%2C.%5B%5D123"

フォームのエスケープとか URL のコンパクションとかやってくれるとこはまだ知らない

830 ：デフォルトの名無しさん：2009/08/13(木) 16:07:00

あまりにカオスだからいっそStringのメソッドに入れてしまおうか、
という話がでたくらい

831 ：デフォルトの名無しさん：2009/08/13(木) 16:27:39

>>830
Web特化のPHPならあり得る選択だろうけど、Rubyでやると賛否の否の方が圧倒的だろうな
なによりPHPを馬鹿にできなくなるし

832 ：デフォルトの名無しさん：2009/08/13(木) 16:33:11

現実の問題を解決する道具としてプログラム言語があり、
現実として Ruby が Web でよく使われているのに。

833 ：デフォルトの名無しさん：2009/08/13(木) 16:35:47

>>825
HTMLをエスケープするだけのためにあんなでっかいライブラリ呼んでられん

834 ：デフォルトの名無しさん：2009/08/13(木) 16:38:55

今はrequire 'cgi/util' するのが正解かな

835 ：デフォルトの名無しさん：2009/08/13(木) 17:06:57

はいはいみなさい便所の落書きお疲れ様です。
ここでなされた議論なんて一切参考にしないし
むしろ採用しないような力が働くからそのつもりでお願いしますよ。

836 ：デフォルトの名無しさん：2009/08/13(木) 17:26:17

議論された場所なんか関係ないね
参考にしたけりゃするし、気に入らなければしない
もちろん場所によってS/N比は違うが

837 ：デフォルトの名無しさん：2009/08/13(木) 17:34:00

話してるのが気に入らないって書いてる人に対して特にコメントはない

838 ：デフォルトの名無しさん：2009/08/13(木) 18:59:47

>>835
そうならなかったことは歴史が証明してるけどなw

老害って自分たちが苦労して堪え忍んだ不条理を
若いのがこともなげにスルーすると滅茶苦茶ヒステリックにブチ切れるよねw

いい年したオッサンの風体で幼稚極まりないのって見苦しいことこの上ないというか。

839 ：デフォルトの名無しさん：2009/08/13(木) 21:21:24

さすが本スレという感じの流れですね

840 ：デフォルトの名無しさん：2009/08/13(木) 21:42:16

>>838
ま、そのへんは回り持ちだよ。君も後にそうなる。
歴史が証明してる。

841 ：デフォルトの名無しさん：2009/08/14(金) 00:32:24

XML のパーサーがまだ作られていない時、
完璧なパーサーを作ろうとすると、すごく大変だけど、
90% ぐらいを満たすパーサーならば、
楽チンで作れるという話を聞いた。
その 10 % のために、コード量がすごく増えて、
労力と時間を使うのは、もったいないなーと思った。

ライブラリーは、90% を満たせる軽量なものがいい。
だいたい、残りの 10% って使用頻度が少なかったりする。

842 ：デフォルトの名無しさん：2009/08/14(金) 00:42:55

でも、その10%に入ってる機能の1つが必須要件に入っていたりするんだよな

843 ：デフォルトの名無しさん：2009/08/14(金) 04:23:10

9割で良いから。
-> 9割の物をつくる
-> 事情を知らない人が来て出来ない1割に文句を言う。
-> メンテする気がなくなる
-> 放置ライブラリができる
-> 新しいライブラリを作ろう。9割で良いから。

844 ：デフォルトの名無しさん：2009/08/14(金) 04:47:07

っていうか今のRubyの添付ライブラリは9割まではできてる
残り1割というが、1割というのはかなり大きい
「普通に使っていれば絶対に引っかかる」のが1割

845 ：デフォルトの名無しさん：2009/08/14(金) 04:52:51

使用状況を100個集めて、90個くらいまで対応して「だいたい9割できました」と言ってしまうような誤りが多い

実際に起こりうるポピュラーな使用事例は300個くらい存在するにもかかわらず、
一番最初の事例採取が間違っていたがために、実際稼動すると充足率は3割未満だ
添付ライブラリは仕様先行のほうがいいと思う

846 ：デフォルトの名無しさん：2009/08/14(金) 05:10:11

思ったより Ruby が急速広範に使われてしまい、
さくっとライブラリ直そうにも影響範囲がでかくなりすぎて互換性に縛られてどうにもならん

というのが現状のような気がする
Net::HTTP みたいな直し方すら、1.8.6 が広まった今ではもう危なっかしくてできん
1.6 時代ならまだがりごり直せた気がするんだが

847 ：デフォルトの名無しさん：2009/08/14(金) 05:21:12

いっそのこと Ruby++ とか別の言語にしてしまった方がいいのかね

848 ：デフォルトの名無しさん：2009/08/14(金) 05:27:57

本体添付ライブラリは難しくても、gem なら大幅に変わっても見逃してもらえる
gem で事実上の標準ライブラリを作って本体にぶち込むんだ

849 ：デフォルトの名無しさん：2009/08/14(金) 06:08:08

>>848
それしかないだろうな
現状でも「アレをやる場合は添付ライブラリ駆使ではなくgemの○○が定番」というのが分野によってはあるわけだし

850 ：デフォルトの名無しさん：2009/08/14(金) 06:42:22

ねー

たとえばクローラ作ってたとして、HTTPS 対応みたいな、
受け取った URL によってはそもそも絶対使わないようなライブラリがけっこうある場合、

　require 'net/https' if uri.scheme == 'https'

というように、メソッドの途中で条件分岐で require させるのって下品？

851 ：デフォルトの名無しさん：2009/08/14(金) 07:01:49

下品かといえばやっぱ下品だと思うよ
「必要なときに必要なものだけrequire」と書くと、字面はとってもエレガントなんだけどね

RMagick みたいなよっぽど重いやつでない限り、用はなくても最初に全部読むのが基本

852 ：デフォルトの名無しさん：2009/08/14(金) 07:01:50

Rubyは標準添付ライブラリレベルではメジャーバージョンアップごとに結構変わってる。
例えばcsvとかは1.9でFasterCSVへの入れ替えが行われてるし、test/unitもmini/testになってる。
結局不満があるのに変わらない系のライブラリは、責任持って変えようって言う人がいないだけ。
互換性は、別の名前で入れて時間をかけて置き換えっていう手もあるし、どうとでもなる

853 ：デフォルトの名無しさん：2009/08/14(金) 07:11:20

>>850
open-uriは正にそーゆー事をやってるね (ftp|http)
あれを下品だと思うなら下品と言ってもいいのかな

854 ：デフォルトの名無しさん：2009/08/14(金) 07:17:41

caseで書けそうなくらい条件と場所がまとまってて、自分以外のライブラリを呼んでるなら許すと思う
あちこちで細かく自分の下のファイルをrequireするのはやめてほしい気分

855 ：デフォルトの名無しさん：2009/08/14(金) 11:25:07

>>850
autoload使えば、と思ったが、
Net::HTTPSとかがあるわけじゃないのか。

856 ：デフォルトの名無しさん：2009/08/14(金) 20:04:46

net/httpsの中身をnet/httpに移して空にし、net/http側でautoload'openssl'したらどうだろう

857 ：デフォルトの名無しさん：2009/08/16(日) 02:50:52

コミケ2日目の帰路で
・RubyKaigi2009のシャツ
・NetBSDの携帯ストラップ
なんて風体の髭の人を見たんだが、
名のある開発者かなんかだったんだろうか

858 ：デフォルトの名無しさん：2009/08/16(日) 03:16:54

@takano32 ?

859 ：デフォルトの名無しさん：2009/08/16(日) 11:52:53

Rubyﾀｿの萌え萌えRuby入門でも描いて布教しろ

860 ：デフォルトの名無しさん：2009/08/17(月) 16:04:19

githubでフォークしたものが手元にあるんだよ
んで、手当たり次第魔改…気になっていた点を節度を持って改良したんだ
変えた点を細かく記録したコミットが30個くらい入ってるブランチになったんだ
最終的な新機能はお互いに関連する2つなんだけど、
ちょっと大掛かりだったもんで全部記録したんよ

これそのまま公開したらうざいよね？

861 ：デフォルトの名無しさん：2009/08/17(月) 16:08:54

興味持った香具師は粛々とpullするだろうからいいんじゃね？

862 ：デフォルトの名無しさん：2009/08/17(月) 16:14:47

>>860
公開するブランチはcherry-pickとスカーッシュで体裁整えるのが礼儀だろ
時々typo修正とかrevertとかマージの痕跡とか入ったままのがあるけどああいうの問題外
公開してしまったものをコミットで修正するのは仕方ないけど、公開前ならローカルで整頓

863 ：デフォルトの名無しさん：2009/08/17(月) 16:24:17

そのへんよくわかんないよね
commitの粒度とか

Ruby関係ないけどな

864 ：デフォルトの名無しさん：2009/08/17(月) 16:32:47

あー、rubygemのライブラリいじるときってさ、
ファイル追加したらManifest.txtやgemspecにも記述を追加するべきだよね？
コミットごとにCHANGELOGにコミットログをコピペするんだよね？

865 ：デフォルトの名無しさん：2009/08/17(月) 16:43:12

公開されているコミットは
「それだけを取り出して適用して（なおかつ衝突部分だけをなんとかすれば）なんとかなるようになっている一塊」
だから、やっぱ Manifest には書いたほうがいいんでないの
変更が必要になる場所はとにかく最低限衝突させて明示するほうがよさそうだ

rubygems ライブラリにとっての「コンパイル成功」は gem パッケージ生成だろうから
それが失敗する状態で特定のコミットが公開されているというのは片手落ちだと思う

866 ：デフォルトの名無しさん：2009/08/17(月) 16:51:26

commit 前に rake しろとな

867 ：デフォルトの名無しさん：2009/08/17(月) 17:58:46

学生が開発したコードがRubyの本体に
ttp://itpro.nikkeibp.co.jp/article/NEWS/20090817/335588/

何がどう変わるのか、知ってる人教えて。
集まった学生は天才プログラマーですか？

868 ：デフォルトの名無しさん：2009/08/17(月) 18:06:48

Rubyがどんどんカオス化してってるな・・・

やっぱPythonにしておけばよかった・・・

869 ：デフォルトの名無しさん：2009/08/17(月) 18:35:54

>>868
確かに伽藍型開発であるPythonでは想像だにできない愚行だよな。
学生がソースに触れるなんておこがましいにも程がある

870 ：デフォルトの名無しさん：2009/08/17(月) 18:39:58

>>867
サッサーをmatzかと思っちゃった。

871 ：デフォルトの名無しさん：2009/08/17(月) 18:40:15

>>867
これすごいなｗ

裾野が広がって優秀なやつがバンバン育ってるんだろうな
おれは彼らの作るプログラムを利用させてもらうしかないわ

872 ：デフォルトの名無しさん：2009/08/17(月) 18:41:27

中学生とかもうね涙でそう

873 ：デフォルトの名無しさん：2009/08/17(月) 19:35:07

まあ年寄りは年の功で精査検査でがっつりツッコめばいいんだよ
それで全体のバランスが取れてうまくいくようになってる

稀～に経年知識ゼロでもセンスで綱渡りして渡り切れる若い人もいるがぬ

874 ：デフォルトの名無しさん：2009/08/17(月) 19:49:11

>>867
これほんとにその学生が自分で見つけてデバッグしてコード修正したの？
なんかこのセキュリティなんちゃらに箔をつけるために思えるんだけど

875 ：デフォルトの名無しさん：2009/08/17(月) 20:00:19

>　その成果が冒頭で紹介したRuby本体の改良などである。
>開発されたコードは，ベンチマークによってはRubyの性能を約5倍向上させるもの。
>すでに笹田氏の手により，8月15日付けでRuby本体に取り込まれている

すげぇ！この前の５０倍と合わせて最大250倍も高速に！

876 ：デフォルトの名無しさん：2009/08/17(月) 20:02:20

「ベンチマークによっては」だけど、
通常利用でも顕著に高速化の恩恵が受けられるような改良であればいいな
おじさんは隅っこの方で君たちのお世話になりますよ

877 ：デフォルトの名無しさん：2009/08/17(月) 21:52:15

なんか胡散臭い記事だなw

878 ：デフォルトの名無しさん：2009/08/17(月) 21:54:02

おまいらの嫉妬なさけなすぎ
せめて未来ある若者の足をひっぱるなよ

879 ：デフォルトの名無しさん：2009/08/17(月) 21:57:20

いやそりゃある程度持ち上げてはいるだろ
凄い感じの人がいますが未来は不定だから何も凄くないんですヨ、みたいな記事に価値はねえw
それっぽく希望を膨らませる前向き記事にしてこそプロ

880 ：デフォルトの名無しさん：2009/08/17(月) 22:00:08

はてなとかこんなことやってないで
もっとましな有料オプション付けろよ

881 ：デフォルトの名無しさん：2009/08/17(月) 22:04:56

誰か試してみて速くなってた？

882 ：デフォルトの名無しさん：2009/08/17(月) 22:44:17

厨房の頃からrubyみたいな高級言語さわれて羨ましいな。
わしが厨房の頃はZ80アセンブリしか選択肢がなかったもんじゃ。

883 ：デフォルトの名無しさん：2009/08/17(月) 22:46:17

消防の頃からBasicみたいな高級言語さわってた
おいらが通るよ

884 ：デフォルトの名無しさん：2009/08/17(月) 22:48:10

この贅沢もんが！
というおいらは消防の授業でLOGOだったお。

885 ：デフォルトの名無しさん：2009/08/17(月) 22:49:54

考えることが少ない方がいいかもしれない

886 ：デフォルトの名無しさん：2009/08/17(月) 22:53:31

考え過ぎると禿げるしね

887 ：デフォルトの名無しさん：2009/08/17(月) 22:56:11

ストラウストラップが禿げてるのはそのせいか
あんな言語だもんな・・

888 ：デフォルトの名無しさん：2009/08/17(月) 22:59:06

考えすぎると禿げる、が真だとしても、
禿げてる人はよく考えてる、は必ずしも真ではない

何が言いたいかというと、うちの会社の禿げを何とかして欲しいと

889 ：デフォルトの名無しさん：2009/08/17(月) 23:00:05

つまんないよ

890 ：デフォルトの名無しさん：2009/08/17(月) 23:23:37

5倍速くなってV8と同等くらいになるのか

891 ：デフォルトの名無しさん：2009/08/18(火) 02:26:08

むしろアセンブラで組めたほうが将来は有望だろう。
rubyは数十年後には消えてる鴨だし。

892 ：デフォルトの名無しさん：2009/08/18(火) 06:47:06

>>858
なんとも。
とりあえずサンダル履きだったのでサークル参加だったのはほぼ間違いないかと。

893 ：デフォルトの名無しさん：2009/08/18(火) 07:00:51

一般参加者はスプリンターシューズを履いてるからな

894 ：デフォルトの名無しさん：2009/08/18(火) 10:49:19

ttp://www.infoq.com/jp/news/2009/08/ruby-installer
VC6捨てようぜ
あとライブラリ作成者はmingw32をWindowsとして扱えバカ

という話らしい

895 ：デフォルトの名無しさん：2009/08/18(火) 13:51:08

ついに公式ビルド元としてすら期待されなくなったか

とはいえこっちのが健全な流れだよなあ

896 ：デフォルトの名無しさん：2009/08/18(火) 13:54:14

できる人がリプレースというのは正しい
メンテナンス上の問題でVC6だったんだから、メンテナンス上の問題が解消できるならVC6でなくてもよい

897 ：デフォルトの名無しさん：2009/08/18(火) 15:51:51

>>895
> ついに公式ビルド元としてすら期待されなくなったか
なにが?

公式には
・「ruby-installer」はruby本体とは独立したプロジェクト
・「公式ビルド元」というものが存在したことはない
という答えになると思う。

898 ：デフォルトの名無しさん：2009/08/18(火) 17:38:59

うさビルドは9xサポートのためにVC6を使っている。
9xを切れるならばVC6以外を使った方がよい。

899 ：デフォルトの名無しさん：2009/08/18(火) 17:47:02

jperlみたいに残すのもありかなとも思う
古いシステム用のRuby

900 ：デフォルトの名無しさん：2009/08/18(火) 18:20:04

そろそろbccとかtccとかの（今となっては）マイナーなコンパイラを
切り捨ててもいいかも、ってもう切り捨てたんだっけ?

901 ：デフォルトの名無しさん：2009/08/18(火) 20:11:00

>>898
9xのためじゃないよ
バイナリ配布されている外部ライブラリのほとんどがmsvcrt.dllとリンクしているから

902 ：デフォルトの名無しさん：2009/08/19(水) 02:59:01

>>901
この辺の話かな
ttp://d.hatena.ne.jp/Kazzz/20090424/p1
ttp://www.artonx.org/collabo/backyard/?DllLoadOrder

903 ：デフォルトの名無しさん：2009/08/19(水) 03:08:28

ttp://www.artonx.org/data/Sapporo2008/ASR.pdf
の6ページ目あたりでもそんなことを話していたんだと予想

904 ：デフォルトの名無しさん：2009/08/19(水) 18:04:41

>>901
逆でバイナリ配布されている外部ライブラリのほとんどは
usaビルドにあわせて泣く泣くmsvcrt.dllとリンクするようにしているんじゃね。

>>894のがデファクトになればみんなあっさり移行するよ。

905 ：デフォルトの名無しさん：2009/08/19(水) 18:58:45

>>904
何もわかってない奴だなあ。

「外部ライブラリ」ってのはこの場合Rubyの拡張ライブラリじゃなくて、
例えばOpenSSLとかGDBMとかそのもののことだよ。

それからね、mingw版もmsvcrt.dllにリンクするんだよ。
拡張ライブラリに関してはVC6で作ったmswin版とmingw版はバイナリ互換。

906 ：デフォルトの名無しさん：2009/08/19(水) 19:06:57

なんでVC6なんだ
2008とか使えねーの？

907 ：デフォルトの名無しさん：2009/08/19(水) 19:45:55

ビルド環境変えるのが面倒だから。に30カラット。

908 ：デフォルトの名無しさん：2009/08/19(水) 20:31:28

唐揚げ食べたいけど食べすぎると死ぬよね

909 ：デフォルトの名無しさん：2009/08/19(水) 21:06:27

>>906,907
この話を最初から全部読み直せ。リンク先も辿って。

VC6以降の全てのVCはそれぞれランタイムDLLがファイル名から異なる。
Ruby本体、拡張ライブラリ、拡張ライブラリが呼び出す外部ライブラリDLL、
が全て共通のランタイムDLLにリンクされていない限り、全体としてのRubyが
正常に動作することは保証されない（たいていはクラッシュする）。

910 ：デフォルトの名無しさん：2009/08/20(木) 01:06:38

python2.5ってmsvcr71.dllとリンクしてんだよね。
OpenSSLとかってどうしてんだ？
自前でビルドしてんのかな。

911 ：デフォルトの名無しさん：2009/08/20(木) 07:45:26

>>905
>mingw版もmsvcrt.dllにリンクする
それはみんなわかってて、だからこそ
mingw版が解法だっていってるんでしょ?

・新しいVisualC++はmsvcrt.dllをリンクしてビルドしてくれない
・mingwのgccは最新でもmsvcrt.dllをリンクできる

って話で。

だからこそ、
>拡張ライブラリに関してはVC6で作ったmswin版とmingw版はバイナリ互換。
だし、それゆえ移行コストが低いからmingwにしようって話になるわけで。

912 ：デフォルトの名無しさん：2009/08/20(木) 08:40:12

そういえば>>894でreadlineをpure rubyなものに差し替えようとしてるのってなんでだろ
GNU Readlineがらみでなんか問題があるんだっけ

913 ：デフォルトの名無しさん：2009/08/20(木) 08:44:46

readlineといえばWindowsで端末の画面サイズをirbに
（というかreadlineに）教えるにはどうすればいいんだろ

cmd.exeの画面サイズを30x120とかにしてると
補完とか改行周りが悲しいことになってかなわん

914 ：デフォルトの名無しさん：2009/08/20(木) 08:57:31

テラ自己解決しました
ttp://d.hatena.ne.jp/jitte/20060501#1146448307

915 ：デフォルトの名無しさん：2009/08/20(木) 09:03:01

>>912
readlineはGPLだから、組み込んだ時点でRubyライセンスが不可になってGPL一択になってしまうこと

Gauche の gosh （irb 相当）が Readline をサポートしないのも同じような理由だと思った

916 ：デフォルトの名無しさん：2009/08/20(木) 11:54:47

>>914
考えようによっては修正がupstreamに取り込まれないまま
数年経っちゃってるともとれるなあ

だれか拡張ライブラリ直す形のコードにしてパッチ投げない?

それかmputたんのgithubにpull requestしたほうがいいのか?

917 ：デフォルトの名無しさん：2009/08/20(木) 12:52:23

_whyが行方不明らしいな。

918 ：デフォルトの名無しさん：2009/08/20(木) 13:33:47

最近、どこかのスレで同じ話題を見た気がするけど
mingw環境でtcltklib.so（stub有効）がコンパイルできない……
解決法を知ってる人がいれば教えてほしい

環境：
ruby 1.8.7-p174, ActiveTcl 8.5.7.0
stub無効ならコンパイルできる

919 ：デフォルトの名無しさん：2009/08/21(金) 06:51:40

XML/HTMLパーサ競争はNokogiriが勝利した
極めて奇妙な形で
あるいは二度と勝てなくなっただけなのかもしれない

…ま、文字コードという魔物には太刀打ちできなかった、のかもねえ

920 ：デフォルトの名無しさん：2009/08/21(金) 06:53:38

Hpricotの公式サイトが消失したしね

921 ：デフォルトの名無しさん：2009/08/21(金) 08:01:34

githubにフォークのミラーがあるよ
ttp://github.com/whymirror/hpricot/tree/master
ま、誰もメインブランチ引き継がなければ消滅だな

922 ：デフォルトの名無しさん：2009/08/21(金) 17:52:19

ttp://www.rubyinside.com/why-the-lucky-stiff-is-missing-2278.html

923 ：デフォルトの名無しさん：2009/08/21(金) 22:18:18

_why 君、どこ行ってもうたんや……

924 ：デフォルトの名無しさん：2009/08/22(土) 00:00:11

なに? また自殺者?

925 ：デフォルトの名無しさん：2009/08/22(土) 00:07:20

英語も読めない人がいるのか

926 ：デフォルトの名無しさん：2009/08/22(土) 00:11:14

まあ、ネット自殺だわな。

927 ：デフォルトの名無しさん：2009/08/22(土) 00:56:10

リアバレしたから引退だってな
せめてコードの引き継ぎぐらいはやってほしかった
海外だと人前でプレゼンしたりしてるのにバレないもんだよな

928 ：デフォルトの名無しさん：2009/08/22(土) 01:14:38

リアバレってRubyを使うというのは誇るべきことでしょ？なんでやめるの

929 ：デフォルトの名無しさん：2009/08/22(土) 01:19:39

「ほー、君は毎日定時に帰ってそういうことしてたんだねぇ。
　職場では、老母の介護をしてるってことで通ってたの、知ってる？」

とかあるだろ。

930 ：デフォルトの名無しさん：2009/08/22(土) 03:14:30

職場でしろよ

931 ：デフォルトの名無しさん：2009/08/22(土) 03:18:28

親バレなのか

932 ：デフォルトの名無しさん：2009/08/22(土) 05:42:33

定時に帰ってりゃ何の問題もないわ

定時じゃなくて会社で内職してたから問題になるんだ是

933 ：デフォルトの名無しさん：2009/08/22(土) 05:47:54

日本だと税金めんどくさい

934 ：デフォルトの名無しさん：2009/08/22(土) 08:04:04

_whyが何を提供していたのかよく知らないけど、仕事で利用してたら
困るだろうなあ。

sqlite3-rubyでも、一時期メンテナがいなくなったことがあったようだけど。
（今は引き継がれている？）

やっぱり、pythonみたいに、標準でいろいろそろっている言語を利用
した方が安全なのか？Rubyも電池をつけてくれるといいんだけど、
人手が足りないんだろうなあ。

逆に、pythonはRubyよりも人手が多いの？

935 ：デフォルトの名無しさん：2009/08/22(土) 08:17:51

標準で色々揃ってるかどうかが重要ではない
「標準以外は一切使えない」ということが重要だろう

第三者が勝手に作った、不安定で、いつサポートがなくなるともしれない、
損害が出たときに請求すらできないような糞野良ライブラリを使う余地がない言語こそ>>934に必要

936 ：デフォルトの名無しさん：2009/08/22(土) 08:51:12

まあ自称ベンチャー実態個人商店、みたいなとこならともかく
まっとうな企業なら「困る」ような仕事においては製品選定時点でサポートを購入できないプロダクトを弾くよな。

スキルがあって安い人手が余ってるなら自力でサポートする、ってリスクの取り方もあるけど
普通は「スキルがあって安い人手」はもっと金を生むところでバリバリ稼いで貰うものだから
まずありえないわな。

RailsはRuby1.8.6処理系含めてRails系全部サポートするようなサービスを売ってる企業があるから、
その辺はコストの問題になるんだろうな。

937 ：デフォルトの名無しさん：2009/08/22(土) 08:53:43

>>932
前の会社の頃のmatzのことかー！

938 ：デフォルトの名無しさん：2009/08/22(土) 09:59:09

>>935
RubyやPythonの標準ライブラリのバグで損害が生じたら賠償請求できるの？
なんかそういうふうに読めるんだけど

939 ：デフォルトの名無しさん：2009/08/22(土) 10:15:04

野良ライブラリよりは可能性がありそうな気はしなくもない

940 ：デフォルトの名無しさん：2009/08/22(土) 10:20:17

所詮民事だから通ることもありそうな感じはするな
判例のために誰か適当な理由で訴えてみたりしないかしら

941 ：デフォルトの名無しさん：2009/08/22(土) 10:24:49

有償ソフトウェアでもそんな補償はしないだろが

942 ：デフォルトの名無しさん：2009/08/22(土) 10:29:39

でも、全く通らないってのもよく考えたら変な話だよな
作りっぱで使用者の完全自己責任でーすなんてプロダクトはこの世にそう多くないぞ

943 ：デフォルトの名無しさん：2009/08/22(土) 10:38:24

無償であれば「瑕疵について一切責任を負いません」という文言は概ね有効
対価受け取った時点で特約自体は無効になる（消費者契約法）

無効になったからと言ってじゃあ即賠償金かというとそうでもないが
「金払ったんだから直せよ」に応じ（切れ）なかった場合に賠償請求が有効だったはず

日本での判例は多くなかったと記憶

944 ：デフォルトの名無しさん：2009/08/22(土) 11:06:19

でもOfficeの不具合で訴えて勝訴した例なんて存在しないわけで

945 ：デフォルトの名無しさん：2009/08/22(土) 12:17:48

>作りっぱで使用者の完全自己責任でーすなんてプロダクトはこの世にそう多くないぞ

Windows

946 ：デフォルトの名無しさん：2009/08/22(土) 12:21:05

ソフトウェアを持ち出す>>945の馬鹿さ加減には眩暈がする

947 ：デフォルトの名無しさん：2009/08/22(土) 12:23:34

>>946

948 ：デフォルトの名無しさん：2009/08/22(土) 12:25:31

ソフトウェアの話じゃなかったのか

949 ：デフォルトの名無しさん：2009/08/22(土) 12:25:40

ソフトウェアの話じゃないのかよｗ

950 ：デフォルトの名無しさん：2009/08/22(土) 12:28:01

わざわざプロダクトって言ったんだしソフトウェアに限らんと思うが
ソフトウェアだけ製造者責任とか吹っ飛んで特別扱いされてるのって変だという話だろ

951 ：デフォルトの名無しさん：2009/08/22(土) 13:06:22

現行法では、わざとウイルス混ぜてライブラリ配布しても罪に問われないんだっけ？
詐欺罪にはなるの？

952 ：デフォルトの名無しさん：2009/08/22(土) 13:26:11

故意だったら多分アウト、過失だったらセーフじゃないかね

953 ：デフォルトの名無しさん：2009/08/22(土) 13:30:46

ウィルス作成罪その他に相当する法律を、という声は昔からないではないけど
なかなか作られないので、直接罰する法律はない。
偽計業務妨害とかで間接的に、ってことになるとおもう。

954 ：デフォルトの名無しさん：2009/08/22(土) 13:35:48

おまいら話が一般的になりすぎですよ

現行ではRuby本体やライブラリの開発者が責任を問われるようなことはないと思うけど
バグのせいでロケットが落ちでもしたら話は変わってくるのかね

955 ：デフォルトの名無しさん：2009/08/22(土) 14:16:43

>>954
法律に引っかからないなら、どんな悪行しようが裁かれることはないでしょう。

956 ：デフォルトの名無しさん：2009/08/22(土) 14:57:10

>>955
悪行をしたら引っかかるように法律は作られてる
刑事は多少制限があるけど、別件逮捕なりの運用で色々できるのはご存じの通りだし、
民事に至っては公序良俗違反でどうとでもできる

957 ：デフォルトの名無しさん：2009/08/22(土) 15:31:17

>>954
人命に直接影響のある部分にrubyを使い、rubyのバグで事故がおこったら
それは汎用品を採用した方に問題あり。
電子部品もソフトウェアも、市販品は普通、そういう用途に使わないでねって書いてあるし。

958 ：デフォルトの名無しさん：2009/08/22(土) 15:42:29

146 名前：デフォルトの名無しさん [sage]： 2009/08/22(土) 14:40:58
http://www.amazon.co.jp/Refactoring-Ruby-Addison-Wesley-Professional/dp/0321603508/
Jay Fields (著), Shane Harvie (著), Martin Fowler (著), Kent Beck (著)

(　ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ

(；ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ
　　_, ._
（；ﾟ Дﾟ）

959 ：デフォルトの名無しさん：2009/08/22(土) 17:15:50

普通の契約では損害賠償は得た対価が上限になってるね
無料ソフトウェアだと責任があっても0円が上限になる
(青天井にしたり、故意に仕込んだ場合は別)

960 ：デフォルトの名無しさん：2009/08/22(土) 18:18:23

Kent Beckがruby本に寄稿する時代か

961 ：デフォルトの名無しさん：2009/08/22(土) 19:31:09

:matzの会社って、Rubyのサポートとかを有償でやってるの？
まっとうな会社が、サポートを得られないプロダクトを利用しないとなると、
Rubyは、自称ベンチャー実態個人商店レベルでしか普及しないでしょう。

Ruby普及のために、有償でこんなサポートができますみたいなアピール
がもっとあってもいいのでは？

962 ：デフォルトの名無しさん：2009/08/22(土) 19:37:32

それを飯のタネにしたけりゃ余所ですればいいんじゃね。
Linusの会社がLinuxサポートしろなんて要望は聞いたことないが。

963 ：デフォルトの名無しさん：2009/08/22(土) 19:54:08

有償サポートｗｗｗｗｗｗｗｗｗｗ

964 ：デフォルトの名無しさん：2009/08/22(土) 21:57:49

Rubyの有償サポートって何を期待してるの？

965 ：デフォルトの名無しさん：2009/08/22(土) 22:21:04

Ruby の有償サポートなんて探せばいくらでもあるよ。

966 ：デフォルトの名無しさん：2009/08/22(土) 23:32:45

で、どこまで責任負ってくれる訳？
オープンソースプロダクト採用の宿命だな。
面倒なのでレッドハットとか使ったりするよな。

967 ：デフォルトの名無しさん：2009/08/22(土) 23:42:29

Ruby 「ここまでしたんだから、せ、責任とってよね！」

968 ：デフォルトの名無しさん：2009/08/23(日) 02:36:35

ume

969 ：デフォルトの名無しさん：2009/08/23(日) 04:34:14

普通に存在するサポート会社じゃなくて「matzの会社が」っていうなら
超初期の頃には
ttp://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/8105

>| ずっと腐り切ったソースばかり見てたんで、リハビリが必要なようで
>|す。はっきり言って全部捨てて(並列処理をサポートする言語で)書き直
>|したいところですが、Enterprise Edition の方のご予定は?(笑)

>マジな話だと仮定すると、うちの会社に連絡くだされば、Rubyプロ
>グラムの商用サポートの見積りは出せると思いますです。

なんて話もあったみたいだけどね。
でもこれってRailsが出てないどころかRuby1.4とかの頃の話だけど。

970 ：デフォルトの名無しさん：2009/08/23(日) 04:39:36

今はRAAがやってくれるでしょ。
http://www.ruby-assn.org/ja/index.htm

971 ：デフォルトの名無しさん：2009/08/23(日) 06:52:40

collect
select
reject
detect
inject

972 ：デフォルトの名無しさん：2009/08/23(日) 07:34:31

expect
elect
connect
effect
respect
correct
inspect

973 ：デフォルトの名無しさん：2009/08/23(日) 07:47:27

>>966
レッドハットもオープンソースだけどな

974 ：デフォルトの名無しさん：2009/08/23(日) 07:53:29

>>973
「オープンソースだから」Redhatを例に出してるようにしか読めないんだが……

国内だとサイオス(旧テンアートニ)あたりがやってるわな

975 ：デフォルトの名無しさん：2009/08/23(日) 07:55:24

it_architect

976 ：デフォルトの名無しさん：2009/08/23(日) 08:29:19

>>966
クローズドソースプロダクトと同じくらいじゃね？
「再現しません。再現できるサンプルプログラム送ってください」
「仕様です」
「バグです。次期バージョンで修正予定です」

977 ：デフォルトの名無しさん：2009/08/23(日) 08:39:59

>>976
ぶっちゃけ払う金次第だろうね
サポートがどうこういわれるMicrosoftだって
プラチナ系のサポート契約してれば
5時間で独自hotfix作って提供してきたりするしな

978 ：デフォルトの名無しさん：2009/08/23(日) 08:47:28

まあね
店で買ったWindowsとMicrosoftと独自契約結んだWindowsではサポートが違う

環境が限られてるから個別修繕できるというのが実は大きいんだが

979 ：デフォルトの名無しさん：2009/08/23(日) 12:09:36

RAAって最近はそっちのことになったのか。

980 ：デフォルトの名無しさん：2009/08/23(日) 17:35:05

WindowsもSolarisもMySQLもOracleも個別パッチを緊急で作ってくれますよ。

981 ：デフォルトの名無しさん：2009/08/23(日) 18:50:31

「いんたーねっとにせつぞくされていること」を調べる方法ってないかな
HTTP でなんかしたいんだが、それの準備がすこし重いので、
そもそも回線が繋がってない状態では前処理自体をしたくないんだ

繋がってないと Net::HTTP の下で SocketError とかが起こることは知ってるんだけど、
Net::HTTP を使い始める前に知りたいんだよね
OS は Linux で、 Windows で動作しなくてもとりあえずは構わない

982 ：デフォルトの名無しさん：2009/08/23(日) 18:59:02

>>981
/sbin/ifconfig の表示を適当に正規表現でスキャン

983 ：デフォルトの名無しさん：2009/08/23(日) 19:36:52

>>981
require 'ping'
Ping.pingecho(hostname,5,'http')

984 ：デフォルトの名無しさん：2009/08/23(日) 19:45:58

>>982に一票

985 ：デフォルトの名無しさん：2009/08/23(日) 19:55:37

>>981
正確な要件は「通信先のホストに接続可能か」な気がする

986 ：デフォルトの名無しさん：2009/08/23(日) 19:59:43

googleにつながるかどうかを調べれば十分じゃね？
「通信先のホスト」よりもgoogleのほうがたぶん堅牢だから。

987 ：デフォルトの名無しさん：2009/08/23(日) 19:59:59

ISPとかからリモートアドレスをもらってないから到達可能性をチェックする必要すらそもそも無いってことだろ

マシン内部だけで完結させたいのなら>>982が簡単
あれの出力と同じことをRubyで行う方法は知らない