Rubyについて Part 36at TECH
Rubyについて Part 36 - 暇つぶし2ch1:デフォルトの名無しさん
09/06/28 16:29:28
オブジェクト指向スクリプト言語Rubyについて扱うスレッドです。
前スレに変なのが沸いて流れてしまいましたが、まったりと行きましょう。

Ruby Home Page
URLリンク(www.ruby-lang.org)

= 前スレ
Rubyについて Part 35
スレリンク(tech板)

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

2:デフォルトの名無しさん
09/06/28 16:31:42
Rubyリファレンスマニュアル刷新計画
URLリンク(doc.loveruby.net)
ライブラリ一覧
URLリンク(doc.loveruby.net)
RubyExtensionProgrammingGuide
URLリンク(i.loveruby.net)
Ruby Hacking Guide
URLリンク(i.loveruby.net)
Symbol < Stringも止める。
URLリンク(www.rubyist.net)
クラスローカルインスタンス変数
URLリンク(www.rubyist.net)
クラス変数
URLリンク(www.rubyist.net)
ローカル変数
URLリンク(www.rubyist.net)
可視性メモ
URLリンク(www.rubyist.net)
URLリンク(blade.nagaokaut.ac.jp)
URLリンク(blade.nagaokaut.ac.jp)
YARV without 1.9
URLリンク(www.rubyist.net)
URLリンク(www.atdot.net)
URLリンク(i.loveruby.net)
JSON
URLリンク(json.rubyforge.org)
URLリンク(webos-goodies.jp)
URLリンク(webos-goodies.jp)
YAML
URLリンク(www.ruby-lang.org)
URLリンク(jp.rubyist.net)
URLリンク(www.namikilab.tuat.ac.jp)

3:デフォルトの名無しさん
09/06/28 16:32:34
Ruby/Gtk+
URLリンク(www.unixuser.org)
URLリンク(takeposo.sakura.ne.jp)
URLリンク(ruby-gnome.sourceforge.net)
URLリンク(ruby-gnome.sourceforge.net)
URLリンク(ruby-gnome2.sourceforge.jp)
URLリンク(psux1.kek.jp)
URLリンク(www.rubycgi.org)
URLリンク(ruby.gfd-dennou.org)
URLリンク(www.magicianmaster.jp)

4:デフォルトの名無しさん
09/06/28 16:33:29
Ruby on Rails
スレリンク(tech板)
URLリンク(jp.rubyist.net)
URLリンク(www.onlamp.com)
URLリンク(kyotosanga.com)
URLリンク(blog.hacklife.net)
URLリンク(www.metadata.co.jp)
URLリンク(japan.cnet.com)
URLリンク(japan.cnet.com)
URLリンク(journal.mycom.co.jp)
URLリンク(www.atmarkit.co.jp)
URLリンク(www.atmarkit.co.jp)
URLリンク(www-06.ibm.com)
URLリンク(itpro.nikkeibp.co.jp)
URLリンク(itpro.nikkeibp.co.jp)

5:デフォルトの名無しさん
09/06/28 17:00:55
>>1-4
Rubyの残念さを象徴するようなわかりづらいテンプレだね
>>3,4とかもうURL羅列してあるだけで何がなんだか

6:デフォルトの名無しさん
09/06/28 17:07:36
「残念」って流行語なのか?

残念(笑)

7:デフォルトの名無しさん
09/06/28 17:25:19
>>1

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

8:デフォルトの名無しさん
09/06/28 18:02:48
前スレ最後まで必死でワラタw

9:デフォルトの名無しさん
09/06/28 18:18:47
このスレタイでよく続くな

10:デフォルトの名無しさん
09/06/28 18:42:29
それだけマイナーだし。

11:デフォルトの名無しさん
09/06/28 19:14:49
>>7
こんなわかりづらいテンプレに疑問を持たないようなユーザーがRuby使いです

12:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/06/28 19:32:05
>>11
文句付けるなら具体的に案を出せば?

14:デフォルトの名無しさん
09/06/28 20:19:54
>>12

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

15:デフォルトの名無しさん
09/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とかっていうマクロから書き始めても二十行くらいでかけてびっくりした。

英語版がここに公開されてる
URLリンク(gigamonkeys.com)

16:デフォルトの名無しさん
09/06/28 21:51:00
>>15
Lisp向きの処理をわざわざRubyに置き換えても無意味
糞言語がゲロ言語になるだけ

17:デフォルトの名無しさん
09/06/28 21:56:30
糞よりはゲロのほうがとか思ってしまった俺オワタ

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


18:デフォルトの名無しさん
09/06/28 23:21:09
>>12
まず、
> pass ... (MATH TEST-ARITHMETIC TEST ~~
この出力が何に由来するものか理解できない俺は、Rubyでのコードもまったく想像できない。

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

19:デフォルトの名無しさん
09/06/29 00:00:58
16bit CRCを求めるライブラリって標準でついてないの?

20:12
09/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:デフォルトの名無しさん
09/06/29 00:48:50
>>19
Zlibにあったような気がしたが、CRC32だな。
githubにCRC16が落ちてたからそれで我慢して。


22:デフォルトの名無しさん
09/06/29 00:49:32
階層化とやらの実装はcaller調べりゃすぐ出来る
むしろ最終的に実行した式(1+1=2とか)を表示する部分に工夫が必要

23:デフォルトの名無しさん
09/06/29 06:23:05
そもそもLISPとか括弧だらけで美しくない
レベルの低い話をRubyのスレに持ちこまないで

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

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

どうしましょ

27:デフォルトの名無しさん
09/06/29 10:03:41
そういや、GitHubでむちゃくちゃ大量にすっごいアドホックなコード追加して
「みんなの見つけてないバグ見つけたのでなおしときましたー」って言ってくる人はいる

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

ということで、A

28:デフォルトの名無しさん
09/06/29 13:09:37
>>24
evalでねじ込めば実現できなくもない・・・・・・

29:デフォルトの名無しさん
09/06/29 16:11:54
びっくり最小にするためにアグレッシブに進化してるな。
URLリンク(codezine.jp)

30:デフォルトの名無しさん
09/06/29 19:13:36
Pythonのことあんま知らんけど、intとlongの互換性ってどんなんだったん?
Rubyの場合、FixnumとBignumはほとんどシームレスだけど

31:デフォルトの名無しさん
09/06/29 19:19:00
なんつーか、Rubyやってる奴ってRubyしかできないんだよな
だから>>12みたいに毛色の違う関数型言語の話題が来ても誰もついていけないという…

32:デフォルトの名無しさん
09/06/29 19:41:20
それはまあ言語歴、プログラミング歴によるのでー

33:デフォルトの名無しさん
09/06/29 19:41:22
LISP やっているやつはこんなのばっか。

34:デフォルトの名無しさん
09/06/29 19:54:54
C言語やJavaやってる人間がいきなり>>12見ても理解不能だろ・・・常識的に考えて

35:デフォルトの名無しさん
09/06/29 20:00:20
C#から満を持して飛び込んできましたがサッパリです

36:デフォルトの名無しさん
09/06/29 20:07:29
SICP読んだ事があるのに分からんかった。

37:デフォルトの名無しさん
09/06/29 20:08:44
解説いらないなら本書く理由も無いからな

38:デフォルトの名無しさん
09/06/29 20:21:26
PL/SQLで頼む

39:デフォルトの名無しさん
09/06/29 20:43:42
>>31
そうそう。逆にPHP使える奴はPerlもHaskellも楽勝だったりする。

40:デフォルトの名無しさん
09/06/29 20:49:03
誰にも構ってもらえてないのか?

41:デフォルトの名無しさん
09/06/29 20:49:13
>>39
ダウト

42:デフォルトの名無しさん
09/06/29 20:51:36
>>39
×PHP
○Python

43:デフォルトの名無しさん
09/06/29 20:52:14
Rubyに限らず他言語を一つでも知ってればlispなんて1日で読めるようになるよ。

44:デフォルトの名無しさん
09/06/29 20:53:39
>>42
それは単純にPython厨に古い人が多くてRuby厨に新しい人が多いってだけだろw
古い人は経験豊富なんだから他言語習得するも簡単

45:デフォルトの名無しさん
09/06/29 20:56:15
PythonはLispのパクリだから親和性が高いのが特徴

46:デフォルトの名無しさん
09/06/29 21:01:19
Ruby会議いくやついる?
あれって、チケット必要なのね。
とっくに売りきれてたorz.



47:デフォルトの名無しさん
09/06/29 21:02:41
RubyにもCommon Lisp成分が入ってると思うが
触ってみると、なるほどご先祖様だと感じられる
Matzが参考にしてると言うだけはある

48:デフォルトの名無しさん
09/06/29 21:05:26
>>39
それはないだろw

49:デフォルトの名無しさん
09/06/29 21:12:04
Ruby も Python も LISP も信者はおかしなのが多い。

50:デフォルトの名無しさん
09/06/29 21:13:46
隔離スレあるんだからいい加減そっち行ったら?

51:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/06/29 21:33:00
evalかな
そうだとすると、違わないんだけどなんか違うようなやっぱり違わないような
なんだこの無形の障壁は

53:デフォルトの名無しさん
09/06/29 22:04:34
evalです。
作ってみて思ったんだが、>>52の気持ちはよくわかる、というか、対象式を表示させるために文字列で渡してevalするという発想自体が捻じ曲がってる気はする。

54:デフォルトの名無しさん
09/06/29 22:26:43
構文木を直接書き下すlispはそこんとこ突き抜けてるからな。

55:デフォルトの名無しさん
09/06/29 22:30:23
1年ほど前からスピードランニングやってます。
貧乏なので生活費辛くなってPart9で中断してますが。。

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

56:デフォルトの名無しさん
09/06/29 22:31:14
↑誤爆した。すまん

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


58:デフォルトの名無しさん
09/06/30 01:19:50
Proc#to_sあたりでコード片の文字列に戻せたならeval避けられそうなんだけどね

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

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

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

59:デフォルトの名無しさん
09/06/30 06:52:46
いいかげんウザいよ

60:デフォルトの名無しさん
09/06/30 10:25:45
お前はなんの話題なら納得するんだ

61:デフォルトの名無しさん
09/06/30 12:11:29
まぁ、Array#cdrなんて無くても ary[1..-1]で済むからなぁw

62:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/06/30 13:07:24
> 5分ほどで書いたから汚くてごめん。
謝るくらいなら5時間できれいなものを書け

64:デフォルトの名無しさん
09/06/30 13:28:35
2chのレスのために5時間かけるくらいなら、5分で書いてゴメンするほうを選ぶわな。
みんながみんな、2chに張り付いているわけじゃない。63みたいに。

65:デフォルトの名無しさん
09/06/30 13:29:48
なんで1円にもならんことに5時間もかけにゃならんのだ。

66:デフォルトの名無しさん
09/06/30 13:36:37
>>64-65
だったら一々言い訳つけて女々しいレスすんな

67:デフォルトの名無しさん
09/06/30 13:42:14
こいつ前スレの>>971だろ
酷い劣等感だ

68:デフォルトの名無しさん
09/06/30 14:12:26
Ruby ユーザの脳味噌の中身は PHP みたいですね

69:デフォルトの名無しさん
09/06/30 22:19:01
>>67
そんなわけないだろ。
ちなみに前スレでやり合ってたのもおれじゃない。
監視する価値を感じなくなったからもう書き込むことはないよ。じゃあ

70:デフォルトの名無しさん
09/06/30 22:24:37
ここまで我慢してたけど監視する価値でフイタ

71:デフォルトの名無しさん
09/06/30 22:32:29
watchの機械翻訳かもな
外国のお客さんは大事にするべきかもよ

72:デフォルトの名無しさん
09/07/01 00:41:49
るびまきてるね、編集乙
だが松江Ruby会議と仙台Ruby会議は福岡開催じゃNEEEE


73:デフォルトの名無しさん
09/07/01 01:52:16
>>72
ワロタwww
広島Ruby会議も栃木で開催されてるよ!

74:デフォルトの名無しさん
09/07/01 02:19:50
Ruby会議って面白いですか?
「はじめてのRuby」を一通り読んだ程度の人間が行っても場違いでしょうか?

75:デフォルトの名無しさん
09/07/01 05:30:43
教祖に有って、誤利益の有るツボとか買いたければ参加してみるのも一興。

76:デフォルトの名無しさん
09/07/01 06:54:36
>>72-73
普段どういうコードを書いてるか目に浮かぶようだ

77:デフォルトの名無しさん
09/07/01 10:11:31
Ruby ユーザの質は PHP みたいですね

78:デフォルトの名無しさん
09/07/01 11:12:35
>>77
仲の悪い奴らを一緒に語ると、変なのが湧いてくるからやめてくれ。

79:デフォルトの名無しさん
09/07/01 14:31:17
そもそもperlの再発明だしね。

80:デフォルトの名無しさん
09/07/01 15:24:28
rubyはperlの…とは良く言われるが、一体rubyのどこがperlな訳?
perlオリジナルの機能でrubyが模倣したモノって何よ?

81:デフォルトの名無しさん
09/07/01 15:25:40
>>80
模倣じゃなくて劣化再発明
だからRubyはPerlではないし、Perlの代わりにはならない

82:デフォルトの名無しさん
09/07/01 15:40:54
やっぱり無いんだ、そもそもperlこそがパクリ言語だもんな
そーゆー意味では劣化再発明と言うのは当たってるか

83:デフォルトの名無しさん
09/07/01 16:01:39
RubyがBlack PerlをパクってZen of Rubyを隠しコマンドに入れたのは超有名

84:デフォルトの名無しさん
09/07/01 16:51:33
コマンドラインオプションとかif/unless修飾子とかredoとかだってグーグル先生が
あとperlが出典かわかんないけど、メソッドだと同じ名前のものが腐るほどあるよな

85:デフォルトの名無しさん
09/07/01 18:37:48
他の言語からも取り込みまくってるから、perlと特に似てるって感じではない
いろいろな言語のいろいろな特徴・アイデアを取り込んだのがRuby

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


>>83
詳しく

86:デフォルトの名無しさん
09/07/01 22:57:04
perlっぽい使い方を想定してる所は有るね。
松本教祖謹製perlってところか。

87:デフォルトの名無しさん
09/07/01 23:38:09
perlパクってるくせに
perlからの脱却とか言ってperlの悪口ばかり言ってるのも面白いよね

88:デフォルトの名無しさん
09/07/01 23:47:24
>>87
こんなところにまでわざわざご苦労様です

89:デフォルトの名無しさん
09/07/01 23:49:07
rubyはawkのパクり。

90:デフォルトの名無しさん
09/07/01 23:54:52
とりあえず国産言語だから、という理由で覚えてみてる。
scala見たいな別の言語が出てきたら使いたいなー


91:デフォルトの名無しさん
09/07/02 00:46:08
でも国産言語だと世界でメジャーじゃないのがねえ。

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

92:デフォルトの名無しさん
09/07/02 00:59:57
むしろ国産言語じゃ世界的に普及しまっくてる方じゃね?

93:デフォルトの名無しさん
09/07/02 01:03:09
>>87
だからperlからパクったものをあげてみろって
今んとこ出てるのはif,unless(while,until)修飾子とredoな
# 関数名とメソッド名が似通ってるのはUNIX文化から来てるからperlは関係ない

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

94:デフォルトの名無しさん
09/07/02 01:10:03
>>92
まがりなりにも世界的に利用者のある国産言語と言われても思いつかない
KL/1ぐらい?Prologの世界では有名なのかも分からんが、
とてもメジャーとは言いがたいと思う

95:デフォルトの名無しさん
09/07/02 01:18:19
お堅い洋書を読んでいてもRubyの名前は当然のように出てくるぞ

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

96:94
09/07/02 01:20:54
あああRubyを除いての話

97:デフォルトの名無しさん
09/07/02 01:52:35
>>94
Lisp 界隈だと KCL (Kyoto Common Lisp) とか ISLISP くらいかねえ
まあ、 KCL は言語じゃなくて処理系だし、 ISLISP は ISO 標準のわりにあまり見掛けないけど

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

99:デフォルトの名無しさん
09/07/02 06:00:57
Rubyは国産でも日本語対応がいいわけじゃないから何のメリットもないよ

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

100:デフォルトの名無しさん
09/07/02 06:32:18
標準で日本語の文字コード変換機能を備えてる訳でもないしな。

101:デフォルトの名無しさん
09/07/02 09:12:18
>>99-100
( ゚д゚)ポカーン

102:デフォルトの名無しさん
09/07/02 09:23:08
>>100は皮肉だろ。たぶん

103:デフォルトの名無しさん
09/07/02 10:45:01
>>93
コマンドラインオプションは既に出てるでしょ。
あと、特殊変数の類はほぼ全部perl由来だね。
それに絡んで、Kernelの一部のメソッド類が$_を特別扱いするのもperl由来。

104:デフォルトの名無しさん
09/07/02 12:05:42
> 日本産ではあるが日本語の取り扱いは他の言語と同レベルで、特にRubyとしてのアドバンテージはない。

どこからの引用だそれ?

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

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

105:デフォルトの名無しさん
09/07/02 12:12:31
パクっただのなんだのなんてネタは前世紀で終わらせとけよw

106:デフォルトの名無しさん
09/07/02 12:59:23
なぜこんなに多くの人が日本語の扱いに困っているんだろう。
それを考えてみることも必要。

107:デフォルトの名無しさん
09/07/02 13:01:13
> 多くの人が日本語の扱いに困っている

困ってるのか?

108:デフォルトの名無しさん
09/07/02 13:12:38
>>106
バカだからだろw

109:デフォルトの名無しさん
09/07/02 13:23:37
Ruby ユーザの日本語の認識は PHP の mb_* 並ですね

110:デフォルトの名無しさん
09/07/02 13:41:08
辞書順ソートが標準でできないとダメとか言いたいのか?

111:デフォルトの名無しさん
09/07/02 17:51:07
>>87
スリップストリームに使う車体は
追い抜くためにありますので。

112:デフォルトの名無しさん
09/07/02 23:21:01
>>104
> 日本語対応は他のスクリプト言語と比べて特徴的な所
日本語対応…?
対応…?

113:デフォルトの名無しさん
09/07/03 01:06:20
JISで統一すれば良かったのに、EUCとかSJISを使い続けるのを許してた。
結局、UTFなんて新しいコードがもう一つ増えたしなあ。
欧米だと、utfとascii/iso8859がちゃんとマップしている。

114:デフォルトの名無しさん
09/07/03 01:10:23
今さら去年のRubyConfでのmatzの基調講演を見たが、
ことさらloveだとか強調されるとキモい

115:デフォルトの名無しさん
09/07/03 01:49:57
Ruby愛を語った講演というと、むしろRuby会議2007のDave Thomasを連想する
生で見たことはないが、ニコニコ動画に転がってたと思う
ユーモアたっぷりにRubyを語ってるのは面白かったw

116:デフォルトの名無しさん
09/07/03 02:00:56
C(++)系のプログラマに pack/unpack を直感的に理解してもらう
うまい説明の仕方ってあるだろうか?


117:デフォルトの名無しさん
09/07/03 02:17:19
>116
ソースコードを読ませる。

118:デフォルトの名無しさん
09/07/03 02:35:41
>>116
Cで構造体なんかをfread/writeするコードと
Rubyでpack/unpackするコードを並べて見せればいいじゃまいか

119:デフォルトの名無しさん
09/07/03 04:04:30
char* <=> struct* のキャストにbase64等の便利機能を加えた物、とか

120:デフォルトの名無しさん
09/07/03 08:49:39
それCで書けるなら、Cのほうがいいって結論に成る。
おまいらだと、rubyで書ける事をわざわざCで書かないだろ。

121:デフォルトの名無しさん
09/07/03 08:51:15
むしろC/C++プログラマの方が理解しやすいだろ
ネイティブのintとかエンディアンがどうこうとか日常だし

122:デフォルトの名無しさん
09/07/03 09:51:45
この論点のずれ具合が巨大掲示板の醍醐味。

123:デフォルトの名無しさん
09/07/03 10:42:33
pack/unpackなんて実質的にCプログラマのための機能だろう。
直感的にもなにも、C構造体そのものやん。

124:デフォルトの名無しさん
09/07/03 12:23:48
すいません。どなたか、初心者スレたててください(´・ω・`)
おながいします

125:デフォルトの名無しさん
09/07/03 12:32:03
>>123
あれはRubyらしく操作するということをハナから放棄したシロモノだよね

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

126:デフォルトの名無しさん
09/07/03 12:41:00
初心者スレって意味あるのか?

127:デフォルトの名無しさん
09/07/03 12:44:48
そりゃ初心者は一定数いるだろうし、
初心者が卒業する一方で新しい初心者も出てくるだろうし
大抵の言語スレで初心者スレがあるのを見ても、あったほうがいいんでない

128:デフォルトの名無しさん
09/07/03 12:54:14
スレ立てトライしてみる

129:デフォルトの名無しさん
09/07/03 12:58:46
Ruby 初心者スレッド Part 29
スレリンク(tech板)

130:デフォルトの名無しさん
09/07/03 13:01:50


131:デフォルトの名無しさん
09/07/03 14:28:28
>>113
EUC-JPもShift_JISもJISベースですがなにか


132:デフォルトの名無しさん
09/07/03 15:08:43
だから何なのかサッパリわからんレスの最後に、なにか、とか書かれてもな。

133:デフォルトの名無しさん
09/07/04 12:13:23
Shift_JIS と名乗って CP932 の文字使ってる Web ページは爆発しろ
あと ~ と 〜 でどうにかなるページももれなく爆発しろ

134:デフォルトの名無しさん
09/07/04 14:33:05
どか~ん

135:デフォルトの名無しさん
09/07/04 14:46:00
ラテン文字入ってるのに us-ascii と名乗ってるページがあるのと同じようなもんかな、と思うことにしてる

136:デフォルトの名無しさん
09/07/04 17:59:45
何も言わないと、iso8859が仕様ですがなにか?

137:デフォルトの名無しさん
09/07/04 18:10:17
ラテン文字てーと
ABCDEFHIKLMNOPQRSTVWXZ
こうですか。Gもか。



138:デフォルトの名無しさん
09/07/04 18:16:28
>>136
US-ASCIIって名乗ってるって言ってるじゃん

139:デフォルトの名無しさん
09/07/07 09:34:04
しつもんー
Ruby は外部 iconv のバージョンとか構成とか関知してないよね
WINDOWS-31J が使えない Iconv モジュールとか存在しうるよね
でも SHIFT_JIS は期待していいよね

140:デフォルトの名無しさん
09/07/07 09:45:11
URLリンク(www.gnu.org)
> Japanese
>   EUC-JP, SHIFT_JIS, CP932, ISO-2022-JP, ISO-2022-JP-2, ISO-2022-JP-1

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

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

141:デフォルトの名無しさん
09/07/07 20:46:44
ISO-2022-JP系で使ってるようなエンコーディングを
外部とのデータ交換用ではなく内部で使おうとするのは
かなり技術的なセンスが欠落してるよな

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

142:デフォルトの名無しさん
09/07/07 20:48:51
メール前提だと文字化けしない事が重要なので、一切変換せず扱えるのも大きい。
バイト文字列として扱えば良いけどね。

143:デフォルトの名無しさん
09/07/08 00:03:58
これからの時代は文字コードはUnicode系しか認めん。
みんながテキストファイルをUTF-8にしておけば文字コード関係のトラブルは格段に減るのに。

144:デフォルトの名無しさん
09/07/08 00:19:07
メール程度の日本語を使いたいだけならUTF-8一択で問題が極小になるという
現代の真実が主流になるのは一体いつのことだろう。
Outlookか?Thunderbirdか?鶴亀か?Beckyか?正直何が悪いんだ?

145:デフォルトの名無しさん
09/07/08 08:33:31
フォントとグリフと文字集合とエンコーディングを分けて話さないと
CSIの怖い人がきそうだな


146:デフォルトの名無しさん
09/07/08 09:09:34
文字集合とエンコーディングとcharsetを区別して
(定義を暗誦するとかではなく)日常的に使える人は日本で一握りだろうな

147:デフォルトの名無しさん
09/07/08 10:42:18
言語と用字(スクリプト)の区別とかもだねー。



148:デフォルトの名無しさん
09/07/08 23:31:08
オブジェクト指向だと、メソッドの長さは15行程度ってえらそうな人が書いてたですが
そんなものなの?…

149:デフォルトの名無しさん
09/07/08 23:41:37
>>148
そうとは限らないが、たいてい短い方が好ましいのは確か

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

150:デフォルトの名無しさん
09/07/09 00:10:03
なるほど…しっかり分割していけば、だいたいその程度に収まる事が多い
という感じか・・・

151:デフォルトの名無しさん
09/07/09 00:18:58
javaはクラスやメソッドが長いって馬鹿にするやつが多いけど
あれはeclipseで補完するもんなのにわかってないおん

152:デフォルトの名無しさん
09/07/09 00:32:54
補完機能つきの重量級IDEを使わないと仕事にならないということですね、分かります

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

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

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


155:デフォルトの名無しさん
09/07/09 01:01:34
LL言語て

156:デフォルトの名無しさん
09/07/09 01:04:36
牛刀で鶏なんて表現知らなかった・・・
あまりに上手いこと言えてて誰かの名言か何かと思えば故事だったのか

157:デフォルトの名無しさん
09/07/09 01:11:20
漏れが知ってるぐらいだから結構知られてる表現じゃないか

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

158:デフォルトの名無しさん
09/07/09 01:47:56
RAS症候群はわかりやすい意思疎通を行おうとする正常な人間の証だろ

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


159:デフォルトの名無しさん
09/07/09 02:06:11
>>158
ほう、現在のDVDが何の略かご存知とお見受けする
ぜひ御教えを請いたいものだ

160:デフォルトの名無しさん
09/07/09 02:27:42
今のDVDはDVDの3文字を擁する規格だからな
まーどうでもいいっちゃどうでもいいが
あと「LL言語」は日本語としては普通
LLとだけ書かれてもよーわからんし、読むときもLの部分だけ訳して考えてなどおるまいて

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

161:デフォルトの名無しさん
09/07/09 03:18:01
「軽量言語」でええじゃろ

162:デフォルトの名無しさん
09/07/09 06:52:36
普通にLLつってるな。
文脈でわかるもんだし。

163:デフォルトの名無しさん
09/07/09 07:14:23
LLと呼び習わされる言語群、という程度の意味合いしか持たせてないからLL言語と言ってる
そんな引っかかるほど頻繁に使う言葉じゃないし

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

164:デフォルトの名無しさん
09/07/09 11:05:35
>>151
名前の長さの話なんか誰もしてないぞ。

165:デフォルトの名無しさん
09/07/09 11:14:11
>>151ではないが名前の長さのことなんて言ってないと思うぞ

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

166:デフォルトの名無しさん
09/07/09 11:26:13
Java の Eclipse に負けている Ruby の emacs/vi の機能ってなに?

167:デフォルトの名無しさん
09/07/09 11:39:09
>>166
はやーい

168:デフォルトの名無しさん
09/07/09 11:57:41
eclipse のほうが遅い

169:デフォルトの名無しさん
09/07/09 12:05:47
Emacs や vim のほうがエディタとしての体をなしている、というあたりだな

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

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

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

171:デフォルトの名無しさん
09/07/09 12:46:58
irbのは実行中のインスタンスバイナリが手元に存在してるからできる芸当だろ

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

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

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

173:デフォルトの名無しさん
09/07/09 12:58:41
えー、

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

C.new.

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

174:デフォルトの名無しさん
09/07/09 13:05:06
>>173
それが出ないのはさすがに諦めていいんじゃないかと思う。

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

176:デフォルトの名無しさん
09/07/09 13:10:54
実際Netbeansは内蔵のjrubyで解析かけてるし、vimもrubyと連携してオムニ補完してるんだけどね。

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

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



177:デフォルトの名無しさん
09/07/09 13:17:59
> require した完成済みのクラスやモジュールのメソッド?
これは ri あたりから引いてくるのが既にあるな
fastri が動作しなくなって久しいが

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

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

178:デフォルトの名無しさん
09/07/09 13:25:21
>>177が最近の技術に疎いだけというオチがつく悪寒
vimの奴のソースでも見てみたらいいんじゃね?

179:デフォルトの名無しさん
09/07/09 13:29:02
そのへんで楽したいなら無理せずにJavaやれよJava
静的言語は素晴らしいって実感するぞ

180:デフォルトの名無しさん
09/07/09 13:31:00
Java をずっとやってきて、動的言語の素晴らしさを実感しているけど?
用途によるね。

181:デフォルトの名無しさん
09/07/09 13:35:09
Rubyでメソッド引数の型をアノテーションか何かで註記する標準的な方法って
無いの?
いくら動的型だからって、或る程度想定してるクラスの範囲ってあるでしょ?

182:デフォルトの名無しさん
09/07/09 13:37:45
>>181
マジでなんもないよ
必要なメソッドさえ動作すれば何でもいいから

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

183:デフォルトの名無しさん
09/07/09 13:41:53
よくわからんけど、
Eclipse(Aptana Rad Rails)より Netbeans Ruby のほうが、
補完の候補が出てくるのが速い気がする。

184:デフォルトの名無しさん
09/07/09 13:43:59
まあメソッド定義から与えられた引数がどう使われるか(どんなメッセージがsendされるか)
追跡して、引き数に指定できる変数を絞り込むぐらいなら出来る。

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

185:デフォルトの名無しさん
09/07/09 13:53:54
>182
えーと、逆に言えば、メジャーなマニュアルシステムを選べば、
標準的とまでは言わないまでも、まぁまぁ一般的な型の註記法があるって感じ?
例えば?

186:デフォルトの名無しさん
09/07/09 13:55:27
>>182
yard流行ってないよね
URLリンク(yard.soen.ca)
最初はきちんとクラスを書いていたものの「Rubyだとホントはどんなクラスでもいいんじゃね??」とか
気づいてしまった人が多いのではないかと推測

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

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

187:デフォルトの名無しさん
09/07/09 14:04:09
>>186
yardoc の引数のはたくさん書かなきゃいけなくなるからめんどくさくなるんだよ
each で回せればなんでもいい場合は [#each] とも書けるが、必要なメソッドったって結構あるしなー

188:デフォルトの名無しさん
09/07/09 14:08:32
マニュアル書くのめんどいメソッドは駄目メソッドという教育効果が

189:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/07/09 16:01:31
is_a? ではなく respond_to? で制限をかけることを思いついた
が、使うメソッド全列挙がめんどいのでやっぱり駄目だな

191:デフォルトの名無しさん
09/07/09 16:20:01
respondで縛ると結局JavaのXXXableインターフェースみたいになっちゃうからね

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

192:デフォルトの名無しさん
09/07/09 16:30:29
phpunit なら PHPDoc をある程度自動生成するのにね
yardoc を生成するのを作ったら

193:デフォルトの名無しさん
09/07/09 16:51:54
いや、その、なんていうかだな、yard の @params のクラス名称の8割くらいの用途は、
実は引数の名称で用が済むんだよ

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

 def hoge(str, params)

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

194:デフォルトの名無しさん
09/07/09 17:02:31
それゆえに真面目にyardを書いても大してうれしくないという話になり、
今のまんまでいいじゃん、でここまで来たのが現状だからなあ

195:デフォルトの名無しさん
09/07/09 17:12:54
変数名に「str」ってハンガリアン記法の問題そのままだなw

196:デフォルトの名無しさん
09/07/09 17:18:59
yardoc の一番よくないところは、必死でクラスを書いても現時点で特にメリットがないということ
このクラスを利用して補完がうまく動くぜーということも特になく、マニュアルの行が1個増えるだけ

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

197:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/07/09 17:30:40
>>196
まあrdocの代表的な実装が、メソッド名クリックとかで
該当部分のソースを見れるようになってるのが
その辺の現実を如実に示してるよね。

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

199:デフォルトの名無しさん
09/07/09 17:39:45
// i に 100 を代入する
i = 100;

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

200:デフォルトの名無しさん
09/07/09 18:02:25
>>197
意味分からない。

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

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

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

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

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

URLリンク(www.amazon.co.jp)

204:デフォルトの名無しさん
09/07/09 19:10:01
ケントベック本というと、読んだ後に引数名を
aTarget
とかにしまくってしまうような偏見がある


205:デフォルトの名無しさん
09/07/09 21:12:14
Smalltalk の場合は、引数の名前の他にキーワードセレクタも引数の使い方を表す情報として使用できる。
この使い方は、Rubyのメソッドが引数をハッシュでとる場合に近い。
ハッシュのキーに意味を持たせれば、値の名前は要らない。

206:デフォルトの名無しさん
09/07/10 01:10:26
「その、まあ」なやつは前RAIDスレにいなかったか?今もいるかもしれんが

207:デフォルトの名無しさん
09/07/10 08:48:47
URLリンク(github.com)
うへえ、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:デフォルトの名無しさん
09/07/10 09:00:33
「いっちゃん外側の纏め用モジュールの扱い」ってのは難儀なとこではある
ここにはメソッドも定数も定義されず、クラスをまとめるモジュール空間の提供としてのみ存在するもの

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

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

209:デフォルトの名無しさん
09/07/10 09:11:47
この場合は ::Mechanize でアクセスできなくすればいいんだろ
…方法思いつかんが
なんかある?

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

211:デフォルトの名無しさん
09/07/10 10:22:55
Object.send(:remove_const, 'Mechanize') とか


212:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/07/10 11:08:50
クラス名は単なる定数で、参照先がたまたまクラスオブジェクトだってことさ。


214:デフォルトの名無しさん
09/07/10 11:14:11
>>210
チラシの裏に提案を書いてもどうにもならないことは自覚してる?

215:デフォルトの名無しさん
09/07/10 11:14:32
class Hoge
end

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

216:デフォルトの名無しさん
09/07/10 11:25:48
__send__でprivate呼べなくなったんじゃなかったっけ

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

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


217:デフォルトの名無しさん
09/07/10 11:59:30
WWW::Mechanize = ::Mechanize

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

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


218:デフォルトの名無しさん
09/07/10 12:23:37
Structといい、一応ファーストクラスオブジェクトなのに
そのへんの仕様で足引っ張ってる感じだw

219:デフォルトの名無しさん
09/07/10 12:45:52
とりあえず、この変更にはユーザーデメリットしかないと思う
俺としてはMechanizeが下手打ってくれて有難いが

220:デフォルトの名無しさん
09/07/10 12:50:29
うっさいよhttpclient

221:デフォルトの名無しさん
09/07/10 12:55:00
今は Anemone かも
あれはASCII 文字使い以外には機能が不足しまくりで、基本機能揃えて実際の現実フォローを行うと
単に Mechanize になるだけなんじゃねともっぱらの評判

222:デフォルトの名無しさん
09/07/10 16:23:46
>>214
それを「気にして」いるのは君だけだよ

223:デフォルトの名無しさん
09/07/10 16:36:05
エスパー参上

224:デフォルトの名無しさん
09/07/10 18:22:16
>>209
module WWW; end
class WWW::Mechanize
end


225:デフォルトの名無しさん
09/07/10 19:40:18
>>220
HTTPのクライアントなんだけどさ、
①HTTP/HTTPSが使えて
②GET/POSTその他メソッドのレスポンスを
 サーバからクライアントへの全文の受信を待たずに
 ある程度の大きさの塊で順次受け取れて
③Windows(mswin32)で動く
ライブラリってなんかあるかな?

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

226:デフォルトの名無しさん
09/07/10 19:50:15
>>225
つまり net/http を使わないってことね

227:デフォルトの名無しさん
09/07/10 20:04:26
>>226
うん。net/httpだと②が出来ないと思う。

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


228:デフォルトの名無しさん
09/07/10 22:04:04
>>227
>動画みたいな数MB~数100MB程度のサイズの場合は
>頭から数10KBとか数100KB程度の大きさでいいから順次取得して
>逐次処理したいんだ。

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

229:デフォルトの名無しさん
09/07/10 22:06:37
不用意にnet/httpを使わない
サーバが対応してるなら、こっから100キロバイトぶんだけくれというHTTPヘッダを送りつけ続ける


230:デフォルトの名無しさん
09/07/10 22:13:31
net/http は逐次処理させるの自体はできた気がする
ただ、どう小細工しても「取得完了時にメモリを数百MB占有」というのは回避できない

231:デフォルトの名無しさん
09/07/10 22:18:25
そういえばopen-uriなんかでもコールバック設定できたよね
ダウンロード状況の進捗とか示すのに使うやつ
逐次処理だけできればいいのならそれで足りそうな気が

232:デフォルトの名無しさん
09/07/10 22:21:33
>>227
230も言ってるけど、逐次処理できるよ
HTTP#getにブロックを渡せばいい
(HTTP.getではできないので注意)

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

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

eventmachine使うとクライアント的な動作についてもイベントドリブンな感じで
実装できるっぽいけど、一から作るのもな、という。
実際目的が同じかはともかくほぼ一から作ろうとしてる人もいるみたいだけど。
URLリンク(blog.masuidrive.jp)


234:225,227
09/07/10 22:30:51
>>232
おお。もっかい確認してみます。

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

235:デフォルトの名無しさん
09/07/11 21:11:56
いよいよAndroidの国内端末(HT-03A)出たね
これでRuby動かしてみた人居る?

236:デフォルトの名無しさん
09/07/13 10:45:37
ruby/tkのビルドで自動でライブラリさがしてくれるようになったね>nagaiさん乙でした
でも、makeにすっごく時間がかかるようにもなってしまった。

237:デフォルトの名無しさん
09/07/16 04:57:23
p Time.at(100).strftime("%H:%M:%S") => "01:01:40"

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

238:デフォルトの名無しさん
09/07/16 05:33:56
TZ=UTC0 ruby -e'p Time.at(100).strftime("%H:%M:%S")'
"00:01:40"

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

239:デフォルトの名無しさん
09/07/16 05:43:31
>>238
ああっ 標準時刻とのずれか!
9時間なら気づけたのに!

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

240:デフォルトの名無しさん
09/07/17 20:43:15
Ruby 会議、初日行ってきたお
通訳しているレオさん(?) かっこよすぎる

声もイカす

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

241:デフォルトの名無しさん
09/07/17 22:04:15
>>240
オレはずっと1Fだったが、ささだ研がブラック研究室ということが分かったよかったw


242:デフォルトの名無しさん
09/07/17 23:09:01
懇親会でアーロンがおよげたいやきくん歌ってた。

243:デフォルトの名無しさん
09/07/17 23:38:33
わざわざ日本に着てまで喋るだけあるな……

244:240
09/07/18 01:32:36
終わったあと、新宿でエヴァ破をひとりで見てから帰ってきた。

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

明日も早起きしないと。

245:デフォルトの名無しさん
09/07/18 09:24:17
>>242
ひげの山男さんマジぱねえっす(日本に馴染んでる的な意味で)

246:デフォルトの名無しさん
09/07/18 14:04:03
>>244
昨日午前中見てきた

247:デフォルトの名無しさん
09/07/18 14:04:50
> ブラックだったのか.....
あれはまぁ自虐ネタだから

248:デフォルトの名無しさん
09/07/19 00:36:45
レオさんは俺の嫁

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

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

249:デフォルトの名無しさん
09/07/19 01:38:29
>>248
URLリンク(yugui.jp)

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

250:デフォルトの名無しさん
09/07/19 16:35:21
実際に誰が動いているかとかはコミットログやChangeLogみるとか、
「Ruby のコミット数ランキング」を見るとか。
URLリンク(dame.dyndns.org)

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

251:デフォルトの名無しさん
09/07/19 23:01:55
ブラック研究室に入ったんだがどうやら俺は限界らしい
URLリンク(www.ci.i.u-tokyo.ac.jp)



映画化決定

252:デフォルトの名無しさん
09/07/19 23:04:02
日本Rubyの会 公式Wiki - 日本Ruby会議2009 アンケート
URLリンク(jp.rubyist.net)


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

253:デフォルトの名無しさん
09/07/20 17:09:14
プレゼンはustreamのrecordedでもうほとんど見れるんだな、すげー時代だ
kwatchのいうテンプレートとAOPってのがamritaとどこが違うのかわからんかった
スレでtenjinのアピールしてたのっていつごろだったっけ

254:デフォルトの名無しさん
09/07/20 18:45:13
AOPはJavaでは比較的知られているけど、たしかにHTMLテンプレートと絡ませると面白いかも。

255:デフォルトの名無しさん
09/07/20 18:50:16
AOPってなに?
アスペクト指向とかいう現状バズワードまがいの代物ですか?

256:デフォルトの名無しさん
09/07/20 18:56:43
バズワードだってw
使ってみたかったんだねw

257:デフォルトの名無しさん
09/07/20 19:58:59
そういえば、matzが言ってたnloopパッチって
結局何で適用されないんだろう

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

258:デフォルトの名無しさん
09/07/20 23:22:08
名前とか?
nloopでは分かりづらくね

259:デフォルトの名無しさん
09/07/22 00:57:45
今時は、なんでもeco。
名前にecoを付ければ、政府援助が付いて、双方ウマウマ。
なわけで、
ecoloop
おいらは、実態を知らんが、高速になるならecoに違いない。

260:デフォルトの名無しさん
09/07/22 06:58:47
>>255
>アスペクト指向とかいう現状バズワードまがいの代物ですか?

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

261:デフォルトの名無しさん
09/07/23 02:44:03
実現方法は別としてLISPとかでも普通にやってることだしね。 > AOP
昔ながらのやり方に新しい名前が付いただけで「バズワード(笑)」になっちゃうわけもなく。

262:デフォルトの名無しさん
09/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>11①11①</TITLE></HEAD><body></body></html>"
=> "<html><HEAD><TITLE>11①11①</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:デフォルトの名無しさん
09/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" "URLリンク(www.w3.)<)
org/TR/REC-html40/loose.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS">
<title>11</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:デフォルトの名無しさん
09/07/23 03:18:51
さくっとパッチ書いて配布しないの?
wktk

265:デフォルトの名無しさん
09/07/23 03:36:14
Nokogiri::HTML.parse(s,nil,'Windows-31J')
のときに実際には
Nokogiri::HTML.parse(s,nil,'CP932')
とやるようなのはすぐに出来るだろうけど、
変換結果とかエンコーディング情報はCP932になっちゃうから、

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

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


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


267:デフォルトの名無しさん
09/07/23 07:39:51
1.8もiconvも捨てて、1.9/transcode使おうぜ!

268:デフォルトの名無しさん
09/07/23 07:41:36
Ruby って不幸なんですね
日本語得意っていうのが嘘に聞こえる


269:デフォルトの名無しさん
09/07/23 07:50:24
iconv と小文字で書いてるのが読めんようだが、
まあ Encode.pm を再発明しなかったのが罪だというならそれはそれで

270:デフォルトの名無しさん
09/07/23 07:51:48
Rubyが日本語が得意だと言ってるユーザーはぶっちゃけいないと思う

271:デフォルトの名無しさん
09/07/23 07:57:22
比較スレとかで「日本語処理が得意」とか書かれてるのは時々見る
つまりRubyを使ってない人にはそう見えるんだろう

272:デフォルトの名無しさん
09/07/23 08:26:58
つまりRubyを使ってない人が
比較スレとかで「日本語処理が得意」とか書いてるのか

273:デフォルトの名無しさん
09/07/23 08:35:47
・文字列処理は得意
・日本語の取り扱いもできる
 →日本語処理も得意なはず!

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

274:デフォルトの名無しさん
09/07/23 08:46:08
日本語版Windowsの標準エンコーディングがUTF-8になれば
UTF-8以外を使う人間はごく短期間で絶滅寸前になるような気もするので、
これから本当にそれほどまでの対応が必要なのかという疑問がいつもある。

275:デフォルトの名無しさん
09/07/23 09:05:08
そもそも「日本語処理が得意」って言い方からして曖昧すぎる
どうすれば得意だと言えるんだ?

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

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




276:デフォルトの名無しさん
09/07/23 09:05:44
朝から活発だな

277:デフォルトの名無しさん
09/07/23 09:16:21
>日本語版Windowsの標準エンコーディングがUTF-8になれば

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

278:デフォルトの名無しさん
09/07/23 09:18:13
>>275
各文字列のエンコーディングを厳密に扱えるのが良い

279:デフォルトの名無しさん
09/07/23 11:11:31
ShiftJIS というか CP932(相当)で作ったファイルがもれなく UTF-8(と共通で決まったもの) で表現できるなら
そりゃ移行はもうあっさり済むと思うんだが
実際はそうではないわけで

280:デフォルトの名無しさん
09/07/23 11:14:23
Summer holidays has come.

281:デフォルトの名無しさん
09/07/23 11:47:25
>>279
漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。
大体、それこそMSお得意の「コードページの切り替え(バグ込み込み)」で
対応できるんじゃねーのとか。

282:デフォルトの名無しさん
09/07/23 12:04:12
ファイルそのものにファイルのエンコーディング情報を含めなかったのが間違いの元
Macと違って

283:デフォルトの名無しさん
09/07/23 12:38:14
>>281
>漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。

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

284:デフォルトの名無しさん
09/07/23 13:13:38
cp932はもれなくユニコードで表現できるでしょ?
じゃなきゃW系APIとかどうすんのかと

285:デフォルトの名無しさん
09/07/23 13:16:48
マクはいろいろ問題が。

286:デフォルトの名無しさん
09/07/23 13:31:41
UTF-8だと日本語が1文字3バイトになるから嫌だと言って譲らない人が稀にいるけど、
そういう人に限って、コンピューターが高速になってるからインタープリタ言語でも問題ないとか言うんだよね。

287:デフォルトの名無しさん
09/07/23 13:34:12
Perlがまだjcode.pl全盛期でUnicodeなんか誰も使ってなかった頃、
Rubyは既に日本語(EUC-JP, SJIS)に対応していた。

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

288:262
09/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:デフォルトの名無しさん
09/07/23 14:13:03
文字コード変換はJavaとかPerlとかがまあ道を切り開いてはくれてるけど
Javaの文字コード周りの大変さとか、
Perlが4から5へ上がったときに配布サイズが膨れ上がった原因の大半が
文字コード変換テーブルのせいだった、とか考えると
Rubyでやるべきかどうか、ってのは悩ましいな。
特にRubyはCSIで頑張るつもりなわけで、より大変な道だし。


290:デフォルトの名無しさん
09/07/23 14:23:46
>>284
もういちど>>279を読もうぜ

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


291:デフォルトの名無しさん
09/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 は
URLリンク(www.gnu.org)
> 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:デフォルトの名無しさん
09/07/23 15:08:47
>>291
事前にコードが仮定できればそれでOKというかベストですね。

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

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

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



293:デフォルトの名無しさん
09/07/23 15:44:28
>>290
具体的にどの文字がUTF-8で表現できないんだ?

294:デフォルトの名無しさん
09/07/23 16:09:56
CP932→UTF-8自体は、記号の意味上はともかく文字の見掛けの形だけは大丈夫だったはず
逆は不可だが

295:デフォルトの名無しさん
09/07/23 16:14:24
>>293
その辺の話はCP932については
URLリンク(ja.wikipedia.org)コードページ932
がまとまってるんじゃないかな

296:デフォルトの名無しさん
09/07/23 18:19:41
UNICODEってあほなの?
文字コード統一するどころか
種類増やしてさらに面倒にしただけじゃないの?

297:デフォルトの名無しさん
09/07/23 18:25:18
iso-8859-*は統一されたんだろ

298:デフォルトの名無しさん
09/07/23 18:56:04
日本国内の文字コードも統一できない民族よりはマシ

299:デフォルトの名無しさん
09/07/23 19:01:14
>>296
JIS EUC-JP Shift_JISを使い分け続けるよりは遙かに分別があるよ

300:デフォルトの名無しさん
09/07/23 19:09:45
100年後も使い分けしつづけてるんじゃないかなぁ?w

301:デフォルトの名無しさん
09/07/23 19:13:33
毛沢東の文化大破壊みたいな歴史的事件でも起こさない限り統一は無理だろ

302:デフォルトの名無しさん
09/07/23 19:24:07
>>291
ubuntuのiconvはglibcのiconv

303:デフォルトの名無しさん
09/07/23 19:25:18
>>301
必要に応じてうだうだ追加してきただけの既存規格が
もうそんなに文化的なものになってるのかw

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

304:デフォルトの名無しさん
09/07/23 19:59:21
文化で人工的でなくて場当たり的でないものはあるのか
それこそ非文化だろ

305:デフォルトの名無しさん
09/07/23 20:23:45
Perl、インターネット、日本語漢字コードあたりは、「とりあえず作ってみた」が
実用に供されていろいろ問題が尾を引いている事物の代表だな。

306:デフォルトの名無しさん
09/07/23 20:25:39
Cもしかり
Javaもしかり
GAEもしかり

307:デフォルトの名無しさん
09/07/23 20:27:02
Rails もしかり www

308:デフォルトの名無しさん
09/07/23 20:28:10
>>305
>「とりあえず作ってみた」

Rubyもその代表なんだが

309:デフォルトの名無しさん
09/07/23 20:34:18
長く大勢に使われる人工物で統一取れているものなんていくつあるんだか。

310:デフォルトの名無しさん
09/07/23 20:40:12
車のエンジンレーキハンドルを変えようかって話は出たり出なかったり

311:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/07/23 20:51:08
> ShiftJIS というか CP932(相当)で作ったファイルがもれなく UTF-8(と共通で決まったもの) で表現できるなら
> そりゃ移行はもうあっさり済むと思うんだが
> 実際はそうではないわけで

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

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

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

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

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

314:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/07/23 21:04:24
>>312
CSIは仕様?それとも実装依存?

316:デフォルトの名無しさん
09/07/23 21:26:15
>>314
DQNというより問題点が理解されてないんでは?

317:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/07/23 21:54:49
> UNICODEってあほなの?
> 文字コード統一するどころか
> 種類増やしてさらに面倒にしただけじゃないの?

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

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

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

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

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

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

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

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

319:デフォルトの名無しさん
09/07/24 01:02:58
本家に取り込んでください
URLリンク(www.moongift.jp)

320:デフォルトの名無しさん
09/07/24 01:30:24
>>319
勘弁してくれ。


321:デフォルトの名無しさん
09/07/24 01:34:01
LTネタだって知らないと本気の拡張に見えそうだな。


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

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


323:デフォルトの名無しさん
09/07/24 08:53:01
ISO-2022-JP-* みたいなイビツなシロモノがスタンダードにならなくて本当に良かったわ
「Unicodeでは全ての文字を含められない」ってのが理由だったがぶっちゃけどうでもいいし

324:デフォルトの名無しさん
09/07/24 09:09:25
新しい文字は放っておいても生まれる。絵文字とか。
というわけで、 UTF-8 系列をとりあえずの基盤として受け入れたのはたぶん結果的にはマシ。

325:デフォルトの名無しさん
09/07/24 09:11:43
余裕をもってUCS4にしようぜ

326:デフォルトの名無しさん
09/07/24 09:28:58
>>324
その割にはサロゲート対応だの、4バイトまでだの、
なかなか中途半端な現状だけどな
UTF-16ってのが諸悪の根元か?

327:デフォルトの名無しさん
09/07/24 09:39:34
UTF-8 は尖兵
ユニコードとやらも意外と悪くないではないかとか思わせるために敢えて本筋を剥いだ草

328:デフォルトの名無しさん
09/07/24 09:48:30
I'm perfect soldier.

329:デフォルトの名無しさん
09/07/24 09:49:35
草とか言うな(w

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

330:デフォルトの名無しさん
09/07/24 09:59:43
最強の尖兵乙

331:デフォルトの名無しさん
09/07/24 11:03:52
>>321
最初からRejectKaigiを狙ってたんじゃないのか?


332:デフォルトの名無しさん
09/07/24 11:45:19
あああ、LTじゃなくてRejectKaigiか。


333:デフォルトの名無しさん
09/07/25 01:02:24
rubyってjisちゃんと扱えないのか。苦労するはずだわ。
ruby捨ててjavaでがんばる。

334:デフォルトの名無しさん
09/07/25 01:06:25
> rubyってjisちゃんと扱えないのか。苦労するはずだわ。
何の話をしてるの?

335:デフォルトの名無しさん
09/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:デフォルトの名無しさん
09/07/25 01:11:42
一文字64bitの新文字コード作ろうぜ

337:デフォルトの名無しさん
09/07/25 01:24:59
>>335
そこが今ひとつわからんのだが、31bitあったのを21bit?にしたのは、
なにか技術的な要請があったの?
それとも、先行したUCS2に引きずられただけ?

256*256*17面(だっけ)にしたのは、どういうことなんだろう。

338:デフォルトの名無しさん
09/07/25 03:13:11
>>337
まず、31bitだったのはsigned int32ね。
0x10FFFFまでなのは、UTF-16の収録限界が由来で、
BMPの0xFFFF+サロゲートペアの(0xDC00-0xD800)*(0xE000-0xDC00)だから

339:デフォルトの名無しさん
09/07/25 06:35:23
そもそもUnicode自体がクソだろ
文字鏡をつかっていればあるいわ

340:デフォルトの名無しさん
09/07/25 07:24:13
現実的にUnicodeより良い物があるの?

341:デフォルトの名無しさん
09/07/25 09:45:27
Unicode一本化されたとこから漸次さらに優れたものに移行すればいいじゃん
カオス状態がUnicodeのおかげでずいぶんましになってる所なのに

342:デフォルトの名無しさん
09/07/25 11:29:26
Rubyスレなのに気付いたらUnicodeの話になってた!

343:デフォルトの名無しさん
09/07/25 11:30:10
文字コードの話はなぜか妙に食いつきがいい

344:デフォルトの名無しさん
09/07/25 11:35:23
開発コアメンバが語るRubyの今とこれから(前編)
URLリンク(www.atmarkit.co.jp)

そろそろ1.8系から1.9に移るころなのかな?

345:デフォルトの名無しさん
09/07/25 12:35:10
>>341
Unicodeがある意味全てを終わらせてしまったので、
優れたものが出てくる余地はない。
Unicodeが優れたものなんじゃなくて、悪貨は良貨を駆逐するという意味で。

346:デフォルトの名無しさん
09/07/25 12:46:51
日本の3つの文字コードへの対応ライブラリパッチのファイルサイズ見れば、色々間違いだと思えるようになるよ

>>344
なんでこう、ちょっとカッコいいポーズしてください写真なん?
や、写真使うのは取材側の人だから要望聞いたほうがいいんだけどさ

Ruby1.9 に移行するのは絶対に間違いない
問題は、そのためのライブラリサポートの手間をいつ誰が取るかだと思う

外国の人はいろんな意味で慎重な移行をやりたがらないと思うんで、
それこそマルチバイトユーザーで最大Rubyコミュニティである日本人の出番なのではないかと

英語のライブラリ作者向けガイド書いた人がどっかにいたが、ああいうの頑張るべきかもしれない

347:デフォルトの名無しさん
09/07/25 12:50:53
弾子飼かと思った

348:デフォルトの名無しさん
09/07/25 12:55:37
とりあえず rubyrb1.9 test/ で Ruby1.9 対応完了とかほざく外人作者さんの調教から

古い rubygem でしか動かないライブラリが捨てられていくのと同じように、
Ruby 1.9 で実際上動作しないライブラリが捨てられていくようになればいいんだけど

349:デフォルトの名無しさん
09/07/25 13:11:14
Railsが1.9でまともに動けば移行が進むんじゃね。


350:デフォルトの名無しさん
09/07/25 14:20:13
つまり asakusa.rb 期待 age?

351:デフォルトの名無しさん
09/07/25 19:38:39
>>344
記事内容とはまったく関係ないし、たぶん写真写りのせいだと思うんだが
2枚目の写真のYugui氏が怖い

352:デフォルトの名無しさん
09/07/25 19:39:58
UTFが、8859と互換なのが大きいからなあ。日本人が使えないって騒いだって、欧米圏は、もう他に移行はしないだろう。

353:デフォルトの名無しさん
09/07/25 19:48:08
>>344
率直に言って恥ずかしいな
写真が気になって記事が頭に入らない

354:デフォルトの名無しさん
09/07/25 19:49:35
>>352
使えるのに使いたくないって騒いでるだけじゃないかと

355:デフォルトの名無しさん
09/07/25 19:54:58
>>351
全てがマイナスに働いている、ある意味レア写真
著者近影に使ったら書籍自体が山積みでお祓いに出されるレベル

もうちょっちいいのなかったんかね

356:デフォルトの名無しさん
09/07/25 20:00:03
>>352
互換じゃないお
互換なのは ISO-8859-1 の部分だけだお
それ以外の 2 から 16 くらいまでの文字は、文字は入ってるけど互換性ないお

357:デフォルトの名無しさん
09/07/25 20:10:41
キモイキモイキモイキモイ
キモイキモイキモイキモイ
キモイキモイキモイキモイ
キモイキモイキモイキモイ

358:デフォルトの名無しさん
09/07/25 20:46:12
>>339
文字鏡はライセンスが問題になって以来、もうないと思うけどな

359:デフォルトの名無しさん
09/07/25 20:47:32
>>351
目が白目むいてるように見えるのが大きいんだろうな

360:デフォルトの名無しさん
09/07/25 22:26:04
ホントにキモイな。

Ruby関係って、他にもキモイやついなかったか?

361:デフォルトの名無しさん
09/07/25 22:32:55
1.9っていうと開発版だから~って思って2.0をずっと待ってた。
そんなに自信もって進められるなら2.0リリースしてくれよ。

362:デフォルトの名無しさん
09/07/25 22:42:04
インタビュー経由で疑問に思ったんだが、Rubiniusって結局何がどう嬉しくなるんだ?
・コードをそのままRubyオブジェクトにできる
・BSDライセンスになる
ことぐらい?

そもそも、CRubyの上で動くRubiniusが、CRubyより速くなるというのがよく理解できない
詳しい人がいればぜひ教えてほしい

363:デフォルトの名無しさん
09/07/25 22:45:51
まだ>>361みたなこと言ってるやつがいるのか

364:デフォルトの名無しさん
09/07/25 22:46:13
1.9使ってたけどRailsを使う必要があったんで1.8に戻した。
1.8でも十分速いし、対応ライブラリも豊富だからこれでいいよ

365:デフォルトの名無しさん
09/07/25 22:49:18
みんな!民主党が大変な事になってるよ。
URLリンク(www.nicovideo.jp)

366:デフォルトの名無しさん
09/07/25 22:49:24
>>360
> 他にもキモイやついなかったか?
好きで使ってる奴でキモくない人間を一人も見たこと無いよ。

367:デフォルトの名無しさん
09/07/25 22:49:36
一方おれは1.9でRailsを使っている。
特に大きな問題はなく今のところすべて回避できている。
回避できない問題もあるんだろうが。

368:デフォルトの名無しさん
09/07/25 22:52:45
>>362
対象の言語でVMを実装できるというところが「きれい」

369:デフォルトの名無しさん
09/07/25 23:50:54
pythonってVMだったか?
Ruby VM より早いPythonってどうなんだろうね

370:デフォルトの名無しさん
09/07/25 23:51:03
心の底から>>361と同意見

MatzはなぜRite=2.0にこだわるんだ
今の1.9.1を2.0にして、Riteを3.0にしたらいいのに

371:デフォルトの名無しさん
09/07/25 23:51:35
【科学】道路に軍手が落ちているワケ、名城大研究チームが突き止める[09/07/24]

スレリンク(hidari板)


372:デフォルトの名無しさん
09/07/25 23:57:09
>>362
アルゴリズムによってはCで書かれたHaskellがCよりも速いのと一緒

373:デフォルトの名無しさん
09/07/26 04:16:25
2.0 への思い入れ云々を除いても、バージョン1をバージョン2に上げるほどの何某があるとは思えん
1.9.1 の次くらいを 2.0 にするならまあアリかなと思う

1.9.1p0 の存在が鬱陶しいと思ってる人は少なくないはずだよ

374:デフォルトの名無しさん
09/07/26 04:27:31
1.9.1 は本体オンリーはともかく第三者ライブラリ全体を含んだ便利度はまだまだだなー、と感じるわけだが、
これが 2.0 だった場合は「バージョン 2.0 とか言ってる割には全然…」だの
「2.0 はアレなので 2.0.4 以降インストールしてください」だのいうことになったと思う

今現在我々が 1.9.1 の使い勝手に抱いている感想は、
それのバージョンが 2.0 だったからといっていい方向に作用したと思われるものではない、はず


次ページ
最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch