Rubyについて Part 34 - 暇つぶし2ch

Rubyについて Part 34 ..

39:デフォルトの名無しさん
09/02/04 18:48:32
>>35
Perlとどっこいどっこい

40:デフォルトの名無しさん
09/02/04 18:50:01
だからWindowsなんて誰も使ってないマイナーOSの話はいいって。

41:デフォルトの名無しさん
09/02/04 19:17:37
>>37
Webインターフェースから日本語で報告するだけ。事前登録は必要だけど。
それさえしてあれば、>>21をこのスレに書くのもredmineに書くのも同じ。
もっとも、もう>>21は直されたみたいだけどね。

42:デフォルトの名無しさん
09/02/04 21:03:54
Win32用のGem ファイルを作成しているのですが、
exec.bat みたいなファイルを c:/ruby/bin とかのパスが通ったところに置きたいのだけど、
どう書けばいいのか分かりません。c:/ruby/lib///xxx/gems/appname/bin/exec.rb とかにインストールされるようにはできたので、
最低限の基本は分かっているつもりです。
RubyGem の rubyforge のページには書いてないような気がするのですが、rake とかでは実現されているので
できるはずなのです。
後ついでに、PlatFormによってコピーするファイルを切り替えられるというのもできたらうれしいです。

43:デフォルトの名無しさん
09/02/04 21:21:31
>>16
サンクスです
>>18
ちょっと自分が知りたい情報じゃないですが、レスありがとうございます。

44:デフォルトの名無しさん
09/02/04 21:30:10
>>39
Rubyはすっとこどっこい

45:デフォルトの名無しさん
09/02/04 21:36:39
>>43
VC とは直接関係ないけど、参考までに
URLﾘﾝｸ(shugo.net)
URLﾘﾝｸ(shugo.net)

46:デフォルトの名無しさん
09/02/04 22:18:06
3927

47:デフォルトの名無しさん
09/02/04 23:18:51
デビアンしか動作保証してないのもどうかと思うがｗｗｗ

48:デフォルトの名無しさん
09/02/05 01:02:31
>>36
見てみたいですけど絶版...
HTML版って内容同じですか？

49:デフォルトの名無しさん
09/02/05 01:18:06
それはCでRubyの処理系を書く本だからスルーしておk
（素晴らしい本であることは間違いないけど）

というかここよりも初心者スレで聞いた方が早いよ

50:デフォルトの名無しさん
09/02/05 16:56:25
>>48
基本的に同じ。
執筆後のアフターフォローとかも少し入ってる。
（最新版のRubyに追従とかはしてないけどね）

51:デフォルトの名無しさん
09/02/05 17:31:45
CでRubyの処理系を書く本なんだけどRubyの中身が分かる
モジュールとかクラスとかスコープの解釈がどうなってるのかとか
他の言語の経験があってこれから初めてRubyを学ぶなら
コーディングするときにも役に立つと思うよ

52:デフォルトの名無しさん
09/02/05 22:58:09
>>51
おなじ様な内容を「実践rails」でも扱ってた

あの本、読み物としては面白かったよ

53:デフォルトの名無しさん
09/02/05 23:10:09
>>45
おお、それで自作クラスが呼び出せるんですね
サンクスです。
もう少しで、自作クラスを呼び出す段階までいけそうです。

今rubygemsをインストールして
mechanizeをインストールしようとしてるんですけど、
zlibがないって怒られてます。
これはどうしたらいいんでしょうか？
とりあえずwindows用のzlibをインストールしたんですがmechanizeのコンパイルでは
依然怒られっぱなしです。

54:デフォルトの名無しさん
09/02/05 23:15:54
module M
def initialize
super
puts "よこどりー1"
end
def hoge
super
puts "よこどりー2"
end
end

class C
include M
def initialize
puts "もともと1"
end
def hoge
puts "もともと2"
end
end

C.new.hoge

これで
もともと1
よこどりー1
もともと2
よこどりー2
って表示したいんだけど、どうすればいいかな

55:デフォルトの名無しさん
09/02/05 23:16:38
URLﾘﾝｸ(d.hatena.ne.jp)

56:デフォルトの名無しさん
09/02/05 23:20:28
>>53
> zlibがないって怒られてます。
> 怒られっぱなしです。
状況説明できない初心者は初心者スレ行け

57:デフォルトの名無しさん
09/02/05 23:27:41
gem install mysql で入れたmysql.soが文字化けするんですが
どうすれば正常に入るんでしょう？

バージョンは↓です

ruby v1.8.7
rails v2.2.2
mysql v5.0.67

58:デフォルトの名無しさん
09/02/05 23:28:50
> mysql.soが文字化け

59:デフォルトの名無しさん
09/02/05 23:36:51
>>54
class C でインクルードしないで

class K < C ; include M ; end
K.new.hoge

で期待する出力は出せるけど、これじゃダメですねそうですね

60:デフォルトの名無しさん
09/02/05 23:41:24
>>54
なんかソースを素直に見る限りでは

> もともと1
> よこどりー1
> もともと2
> よこどりー2

と表示されそうなんだけどな
モジュールのメソッドがガン無視されるのはなんでだろう

61:デフォルトの名無しさん
09/02/05 23:46:10
>>56
分かりました。そうします

62:デフォルトの名無しさん
09/02/05 23:56:14
> モジュールのメソッドがガン無視されるのはなんでだろう

C.ancestors

63:デフォルトの名無しさん
09/02/05 23:59:48
>>60
> モジュールのメソッドがガン無視されるのはなんでだろう

p C.ancestors #=> [C, M, Object, Kernel]

ということで、メソッド探索順がMよりCが先だから、が正解
そもそも include が

[C, Object, Kernel]

のCの1個上に割り込んで

[C, M, Object, Kernel]

とすることでメソッド追加を実現してる機能だから、
「includeで既存のメソッドを上書き」ということ自体がそもそも仕様的にできない

>>59だと

[K, C, Object, Kernel]

にMが

[K, M, C, Object, Kernel]

という順番で割り込むから、実質、MでCが上書きできてる

64:デフォルトの名無しさん
09/02/06 00:08:32
>>63
> 「includeで既存のメソッドを上書き」ということ自体がそもそも仕様的にできない
これって「メソッドをクラスに追加します」とかいうへにょげた説明の割に微妙に不便な実際だよね
「include M はメソッド探索の上位に M を追加します」とかきちんと書いて欲しいなあ

ちなみに extend ならできるが、initialize の上書きができね

c = C.new
c.extend M
c.hoge

もともと1
もともと2
よこどりー2

65:デフォルトの名無しさん
09/02/06 00:14:34
>「include M はメソッド探索の上位に M を追加します」
うおー自作で include 使わないから知らんかった
C にないメソッドのときだけ M が探索されるのね、成程

66:デフォルトの名無しさん
09/02/06 00:38:55
>>57
「mysql.soが文字化け」？？

67:デフォルトの名無しさん
09/02/06 00:39:41
>>63
なるほど
その説明で今更いろいろな事が納得できた…

68:デフォルトの名無しさん
09/02/06 01:43:50
MySQL開発チームメンバーらと起業
MySQLの「生みの親」、サンを離れる
URLﾘﾝｸ(www.atmarkit.co.jp)

69:デフォルトの名無しさん
09/02/06 02:02:57
>>54,63
> 「includeで既存のメソッドを上書き」ということ自体がそもそも仕様的にできない

無理矢理だがこんなんでどうだろう

class C
# この段階では M を include しない
def initialize
...
def hoge
...
end

module X
define_method :initialize, C.instance_method(:initialize)
define_method :hoge, C.instance_method(:hoge)
end

class C
remove_method :initialize
remove_method :hoge
include X
include M
end

C.new.hoge

70:デフォルトの名無しさん
09/02/06 06:15:56
>>54
それclass Cの方で、メソッドの最後にsuper呼んだらうまくいくんじゃね？

71:デフォルトの名無しさん
09/02/06 11:13:41
それはメソッドのオーバーライド（再定義）とsuperがどういうしくみになってるかってことだな

72:デフォルトの名無しさん
09/02/06 11:26:05
実際上は>>59が妥当だな
Ruby におけるメソッドの上書きは「その場」で「実際」に def を実行しないと動作しないから
既存のモジュールオブジェクトを include でがっちょんと接続しただけでは期待通りにはならないと

…そもそもの include っていう名前がまずい気がしてきた
add_parent とか family とかなんかそんなクラス・モジュール関係が変化するという印があったほうがよかったのかもしれない

73:デフォルトの名無しさん
09/02/06 11:30:59
>>72
module M; end
class C; end
p C.ancestors
class C; include M; end
p C.ancestors

[C, Object, Kernel]
[C, M, Object, Kernel]
　　↑このへんがinclude

74:デフォルトの名無しさん
09/02/06 11:38:10
なるほどクラスの内包関係に含むからincludeか！Ruby氏ね！

Mix-inとかの実装上の都合だったのか「モジュールの内包関係にあとから割り込む機能」が欲しくてこうしたのかがちょっと興味ある

75:デフォルトの名無しさん
09/02/06 12:01:02
>74
お前が氏ね

76:デフォルトの名無しさん
09/02/06 13:00:03
つーか普通 module を include するのって抽象クラスを継承するようなイメージじゃないのか?
どう考えても class で書いたメソッドの方を優先して欲しいんだが。

77:デフォルトの名無しさん
09/02/06 15:04:11
いや思いっきり優先されてるだろ
p C.ancestors #=> [C, M, Object, Kernel]
は C にメソッドがない場合にのみ M の中を探す

module M
def msg; "Rubyはうんこ"; end
end
class C
def msg; "Ruby最高"; end
end
class C; include M; end

puts C.new.msg

Ruby最高

78:デフォルトの名無しさん
09/02/06 15:06:07

　・既存のメソッドと同じ名前のメソッドをincludeしたとき super がどうなるか
　・クラスを含んだモジュールをincludeしたときそもそもどうなるか

というのがわかりにくいわぼけーという話だな

79:76
09/02/06 15:59:11
>>77
いやいや、実際そうなってないということではなくて、>>72とかの「期待通り」って、
いったい何を期待しとるんだという話。
Ruby の include のイメージで
>>78の「既存のメソッドと同じ名前のメソッドをincludeしたとき」
みたいな言い方は、普通出てこないんじゃないの? と思うんだが…

80:デフォルトの名無しさん
09/02/06 16:32:17
>>79
つヒント：普通じゃない

81:デフォルトの名無しさん
09/02/06 21:31:50
1.9.1文字コードがどーたらこーたらで既存のコードがうごかねー。
そういうのは2.0でやってくれよ。

82:デフォルトの名無しさん
09/02/06 21:35:47
文字コードなんて1.4でやっとけよ

83:デフォルトの名無しさん
09/02/06 21:56:02
>>81
1.9.0では動作してたものが1.9.1では動かないというのなら姉さん事件ですのでぜひ報告を

84:デフォルトの名無しさん
09/02/06 23:02:12
2.0でやってたらやってたで「3.0でやってくれよ」と言ってるんだろうな

85:デフォルトの名無しさん
09/02/06 23:02:59
なにいってるかわからない

86:デフォルトの名無しさん
09/02/06 23:52:48
なるほど
ありがとうございました

87:デフォルトの名無しさん
09/02/07 00:30:26
どれだー
どれに対する礼なんだー

88:デフォルトの名無しさん
09/02/07 00:38:44
きっと神にだよ。

89:デフォルトの名無しさん
09/02/07 01:33:07
なるほど
ありがとうございました

90:デフォルトの名無しさん
09/02/07 06:13:20
>>84
少なくとも1.9.1でやるよりは10倍マシ

91:デフォルトの名無しさん
09/02/07 07:27:49
複雑だと思うならつかわなきゃいいんじゃねーの？
なんでアホはあるもの全部使わなきゃ気がすまねーの？

92:デフォルトの名無しさん
09/02/07 08:02:17
誰と会話してんの

93:デフォルトの名無しさん
09/02/07 14:07:18
# -*- coding: utf-8 -*-
を行頭に挿入すりゃいいだけだろ？何を恐れることがある

94:デフォルトの名無しさん
09/02/07 14:33:29
>>92
彼は今チャンピオンベルト目指して脳内キャラとスパー中です。

95:デフォルトの名無しさん
09/02/07 14:55:55
>>94
それってつおいの？

96:デフォルトの名無しさん
09/02/07 14:58:32
昔、机の上で左手と右手を戦わせてたときのことを思い出した

97:デフォルトの名無しさん
09/02/07 14:59:40
それなんて色川武大

98:デフォルトの名無しさん
09/02/07 15:08:03
きっと神とだよ。

99:デフォルトの名無しさん
09/02/07 15:08:55
ありがとうございました

100:デフォルトの名無しさん
09/02/07 15:26:06
なるほど

101:デフォルトの名無しさん
09/02/07 15:36:53
がんばれよ

102:デフォルトの名無しさん
09/02/07 15:57:37
>>90
1.9って2.0のβじゃないの？
Rubyのバージョン付けはそういうルールじゃないんだっけ。

103:デフォルトの名無しさん
09/02/07 15:58:21
1.9は1.10のβです

104:デフォルトの名無しさん
09/02/07 16:01:49
>>102
元々はそういうルールでしたが、1.9.1からいきなり変わりました

今は1.9.0が開発版、1.9.1が安定版
それ以降はもうよく分からない

105:デフォルトの名無しさん
09/02/07 16:04:26
>>104
なるほど、知りませんでした。

>>103
確かに。
2.0のβなら1.99でしょうね。

106:デフォルトの名無しさん
09/02/07 16:06:25
>>102
2.0が当分先になりそうだから、
つなぎとして固まった仕様だけ出したのが1.9だったよーな

破壊的な変更のコストはどんどん増える一方ということを考えると、
ブロック内変数とかも含めて、
今のうちに変更しておくという決定は一理あるとは思う

107:デフォルトの名無しさん
09/02/07 16:10:00
1.8と2.0の掛け橋が1.9で、1.8と1.9の橋渡しが1.8.7
ライブラリ作ってるのでなければ、しばらくは1.8.7を常用するのがよい
半年もすれば1.9.1対応ライブラリもぐんと増えよう
ライブラリ公開してる人はとっとと1.9.1入れて対応作業始めてくりゃれ

108:デフォルトの名無しさん
09/02/07 16:13:29
>>107
今年中に1.8.8出るよ？

109:デフォルトの名無しさん
09/02/07 16:14:02
>>108
またそんな夢みたいなことを簡単に信じるんだから

110:デフォルトの名無しさん
09/02/07 16:15:25
>>108
うん、で、そのあとに続く言葉は何？
「だから1.8.6使い続けたほうがいい」？
1.8.8が出るなら今から1.8.7勉強して慣れたほうがよくないか？

111:デフォルトの名無しさん
09/02/07 16:35:19
hpricot(why-hpricot)とmysql(elia-mysql)は
githubで公開しているgemなら1.9.1に入った。
githubのgemはオーナー名が入るのが好かんのだが。

112:デフォルトの名無しさん
09/02/07 16:44:48
Hpricotの復権はあるのだろうか…

113:デフォルトの名無しさん
09/02/07 16:46:56
>>112
Nokogiri はつまるとこ lib-libxml2 なんで、そのへんの不便を突けば並列使用は可能だと思う

114:デフォルトの名無しさん
09/02/07 17:41:37
>>112
なんか、why の人の blog で
「nokogiri の方が速いとか言われてマジブルー。むかついたからパーサー書き直したYO!」
とかいうエントリがあがってた。試してないから速くなったのか知らんけど。

115:デフォルトの名無しさん
09/02/07 17:44:32
速さ云々じゃなくてあの変態APIが（ｒｙ

116:デフォルトの名無しさん
09/02/07 17:56:02
hpricotがなくっても _why の多芸っぷりは憧れる

117:デフォルトの名無しさん
09/02/07 18:39:21
最近似たようなこと書き込みまくってる気がするんだが

module M
class C1; end
class C2; end
end

この場合、C1 と C2 に関係性を持たせることはそもそもできない？
たまたま含まれるモジュールが同じだけで、「知り合い」ではない？

M を改造して

module M_II
class C1; end
class C2; end
end

というものを作りたいんだけど

118:デフォルトの名無しさん
09/02/07 19:17:21
>>110
1.8.7と1.8.8って何か変更あるの？
その時の1.9.1ってどうなるの？

119:デフォルトの名無しさん
09/02/07 19:22:25
1.9という奇数バージョンは開発バージョンだから
2.0まで待った方がいいよ。

120:デフォルトの名無しさん
09/02/07 19:32:46
間違った知識で何を言うか

121:デフォルトの名無しさん
09/02/07 19:43:53
何年も継承されてるルールを変えられると困る

122:デフォルトの名無しさん
09/02/07 19:52:42
文字列処理入ると1.8より遅いのか...

123:デフォルトの名無しさん
09/02/07 19:54:20
不安定版を一応脱した1.9.1が出た時点で、実質「1.9は開発版」という看板は終了だ
従来動作の1.8系列と、新動作の1.9系列という2つの括りになる
むしろ、次の開発版が無いのが気になる

124:デフォルトの名無しさん
09/02/07 19:56:08
>>117
定数とか調べてコピーを作るメソッドを自分で作れ
Application.create とか

あと↓見てよく考えろ。クラスも定数である事を忘れるな
class A
　CONST = :A
　def pconst ; p CONST ; end
　def pselfconst ; p self.class::CONST ; end
end
class B < A
　CONST = :B
end
B.new.pconst #=> :A
B.new.pselfconst #=> :B

125:デフォルトの名無しさん
09/02/07 19:57:42
話をループさせるの好きなんですね、わかります。

126:デフォルトの名無しさん
09/02/07 21:13:30
>>117
> 「知り合い」ではない？
まあ、基本的には。
ネストでも継承でもない場合、基本的に他人。
データ作成クラスとデータ構造クラスとかを知り合い関係のまま再利用させたい場合は適当にネストさせとく。

class DataMaker; end
class Data; end
class SubData; end

という並列構造はそもそもあんましよくない。

127:デフォルトの名無しさん
09/02/07 21:21:54
moduleインクルードすると嬉しいことって
クラスの多重継承の代わりになるってことだけですか？
なんならmoduleなんて排除してクラスの多重継承許しちゃえばよかったのに

128:デフォルトの名無しさん
09/02/07 21:29:31
ClassクラスとModuleクラスを機能的に分けたときのついでなんじゃないかと最近思う

129:デフォルトの名無しさん
09/02/07 21:34:06
>>126
ネストの意味のあるクラス名考えるのがとってもめんどくさいです

130:デフォルトの名無しさん
09/02/07 21:34:10
moduleをファイル指定にするというのはどうだろう

module HogeHoge
class FooBar; end
end
と書いたファイルは名前がHogeHoge.rbでなくてはならない、と
して
require ForBar from "HogeHoge"
とかすんの。

131:デフォルトの名無しさん
09/02/07 21:52:54
1.9系は全部開発版じゃないの? というのは私も思ったけれども、よく見るとRHG巻末に「1.9.0は開発版、1.9.1は安定版」書いてあるからかなり前から公表されていたと言える。
Matzがなにか2.0 featureをあれこれやりはじめたら、そのとき開発版と1.9系安定的開発版を分けますです。

132:デフォルトの名無しさん
09/02/07 21:56:11
てか、単に脳内情報が更新されてない人がいるだけだ
わりと前に「末尾 0 のみ開発版」というのは発表されてたはず
あと、一般的命名法とかけ離れている、直感に反するポリシーだというのが(w

133:デフォルトの名無しさん
09/02/07 22:00:13
>>119
1.9.1も開発バージョンで2.0.0も開発バージョンなんですよね
わかります

134:デフォルトの名無しさん
09/02/07 22:00:14
Rubyの作者ってちゃんと働いてるの？
IBMとかに入って一度リリースエンジニアリングを学んできた方がいいと思うんだが。

135:デフォルトの名無しさん
09/02/07 22:02:38
1.9の開発版はこの先ずっと1.9.0なんか...
それとも1.9.1.0とか

136:デフォルトの名無しさん
09/02/07 22:10:56
あの浅田真央でさえ不調になるとこんなもんだ

137:デフォルトの名無しさん
09/02/07 22:33:00
どんだけ話をループさせるのが好きなんだよ、おまいらはw

138:デフォルトの名無しさん
09/02/07 22:37:21
Rubyの安定版が1.9.1になった理由について
Matz自身が言及してる文章ってどこかにないかな？　あったら教えて欲しい

139:デフォルトの名無しさん
09/02/07 22:38:20
何で英語の方がドキュメント豊富なんだよ
日本で生まれたって理由だけでruby選んだのに
納得できん

140:デフォルトの名無しさん
09/02/07 22:41:35
>>139
日本語ドキュメントが豊富だっていう理由で言語選ばなかったからだろ

141:デフォルトの名無しさん
09/02/07 22:45:55
>>139
日本人があまりドキュメント作る気が無いから

142:デフォルトの名無しさん
09/02/07 22:47:17
用途によってまた違うんだろうけど、日本語ドキュメントの質と量の総合で言うと、
Perl > PHP > Ruby >= JavaScript > Python くらいな気がする今日この頃。

143:デフォルトの名無しさん
09/02/07 23:04:33
公式じゃなくても優良な書籍や解説サイトがあるPerl
公式以外が間違いだらけで公式しか頼れないPHP
公式があれば必要十分なPython

144:デフォルトの名無しさん
09/02/07 23:12:28
Pythonの公式は情報量は多いのに、使いやすさが全く考慮されていないのが痛い。
PHPは公式の出来はとても良い。ただしGoogle検索で出てくる更新されていない公式のコピーサイトがうざすぎる。

145:デフォルトの名無しさん
09/02/07 23:32:49
るびま25号出たー！
まさに今求められている記事のラインナップだ、素晴らしい

146:デフォルトの名無しさん
09/02/07 23:40:12
python信者ってやたらruby嫌うよね？
職場のpython教の先輩方々がみんなrubyアンチだ
何なんだろね

147:デフォルトの名無しさん
09/02/07 23:41:30
>>139
なにもかも、おまえがドキュメントを書かないせい。

148:デフォルトの名無しさん
09/02/07 23:41:39
>>146
犬好きと猫好きみたいなもんだって誰かが言ったと最近どこかで見たが、このスレじゃなかったのかな

149:デフォルトの名無しさん
09/02/07 23:42:48
URLﾘﾝｸ(isitruby19.com) (Is it Ruby 1.9?) というサイトがあった。

150:デフォルトの名無しさん
09/02/07 23:55:41
>>145
1.9スレではリンク張られてたな

151:デフォルトの名無しさん
09/02/08 00:08:25
るびまからリンクされてたFiberの解説を見て
Fiberに対する興味が出てきたんだけど、有効な使い方がよく分からない

確かにThreadよりもシンプルだけど、使い方を探すのに悩む…

152:デフォルトの名無しさん
09/02/08 05:31:54
Rubyの開発ってさ、いつ終了すんの？
早く開発完了してバグ取りと仕様固定化に
力入れてくんないと、怖くて業務に使えないんだけど。

153:デフォルトの名無しさん
09/02/08 06:45:38
>>152
Python、PHP、Java
これらの言語の開発は終了しましたか？　また終了する見込みはありますか？
それが答えです

154:デフォルトの名無しさん
09/02/08 10:30:32
CもC++もC#も終わってないな
終わったのはVBとCOBOLくらいか

155:デフォルトの名無しさん
09/02/08 10:53:42
COBOLも終わってないらしいぞ。
JIS規格の会議とか、最近でもあるし。

156:デフォルトの名無しさん
09/02/08 12:12:19
>>153
Javaは終わってないけど、互換性はそれなりにキープされてるから
ちょっと違う。テスト不要とまでは言わないが、コード修正は不要なことが多い。

>>154
VBも終わってないぞ。文法が違うだけで、中身がほとんどC#と同じという
意味では「終わっている」のかもしれないが。

157:デフォルトの名無しさん
09/02/08 12:18:07
Javaは「仕様が無い言語とか業務使用にありえないから」という理由だけで作られた政治的言語だろ
他の言語と比較するのはそれだけで場違いだ

158:デフォルトの名無しさん
09/02/08 13:39:54
1.9.1でバイナリファイル(画像)を File.read で読み込んだら
data.encoding #=> #<Encoding:UTF-8>
みたいになるんだな。これが Encoding.default_external か。

data.force_encoding('BINARY') するのと、
Encoding.default_external = 'BINARY' するのと、
どっちが行儀がよいのだろう。

とここまで書いて IO.binread の存在を知った。

159:デフォルトの名無しさん
09/02/08 13:59:17
ｇｄｇｄ

160:デフォルトの名無しさん
09/02/08 14:00:19
Pathname#binreadないんだな。

161:デフォルトの名無しさん
09/02/08 14:16:19
1.9.1(って書きづらいな。なんかコードネームでもつけてくれ)はUTF8でソースもテキストも書いとけばドツボにはまることもなくなるのかね。

162:デフォルトの名無しさん
09/02/08 14:20:57
>>161
万事解決かどうかは知らないが、そうしない理由もないだろ。
今日日EUC-JPとか正直なんのメリットもないしな。

163:デフォルトの名無しさん
09/02/08 14:45:23

　・システムがEUC-JPベースだ（オールドなLinuxとか）
　・ Emacs のUTF-8 対応に許せない
　・ターミナルと UTF-8 の関係でイラつく

の 3つの場合が考えられまする

164:デフォルトの名無しさん
09/02/08 15:17:31
そんなマイナー人種は、頑張って苦労するか日本語文字を使わないか
すればいいんじゃないかと。

165:デフォルトの名無しさん
09/02/08 15:19:16
UTF-8 は日本語大体３バイトだしな・・・

166:デフォルトの名無しさん
09/02/08 15:23:44
曖昧な幅のCJK文字とか死滅すればいいのに

>>165
UTF-8というかUnicodeにまつわる問題の多くは文字のバイト数に起因していない
的外れ

167:デフォルトの名無しさん
09/02/08 15:27:49
def val(params = nil)
@val ||= ...
end

とか

def val(params = nil)
@val if @val
...
return @val = ...
end

とかいう、最近わりと市民権得つつある遅延評価風の処理についてなにか一言あれば

168:デフォルトの名無しさん
09/02/08 15:35:00
>>167
irb とひじょーに相性が悪い
普通に書いてると、new した返り値が inspect で表示される瞬間に @val が確定してしまったりしてとてもめんどくさい

169:デフォルトの名無しさん
09/02/08 16:00:25
>>166
単に容量増えるって問題だよ

170:デフォルトの名無しさん
09/02/08 16:59:29
容量気にすんならMIME撲滅するべきだろ

171:デフォルトの名無しさん
09/02/08 17:00:41
XML もですねわかります

172:デフォルトの名無しさん
09/02/08 17:07:37
Rubyでそんなにシビアなもの作ってる人いるんだ。

173:デフォルトの名無しさん
09/02/08 17:09:58
>>167
普通にキャッシュとか言ったほうがいいよ

>>168
評価されるタイミングで結果が変わるメソッドでは使うべきではない

174:デフォルトの名無しさん
09/02/08 17:12:41
cache or memoize

175:デフォルトの名無しさん
09/02/08 17:44:46
>>167
rubyって遅延評価できるんだwww
見る限り遅延評価してるようには見えないが

176:デフォルトの名無しさん
09/02/08 17:49:34
rubyistな後輩がrails使った自社サービス開発してるんだけど
ログイン周りの拡張をする時に、汎用的に使えるようにしようってことで
railsのプラグインを３日ぐらいで作ってた。
javaしか知らなかった俺は素直にすげーって思った。
このフットワークの軽さは惚れるね。rubyじゃなくてrailsがすごいのかもしれないけど。

177:デフォルトの名無しさん
09/02/08 17:55:16
遅延評価と遅延評価風ってJavaとJavaScriptくらいの差があるよね

178:デフォルトの名無しさん
09/02/08 18:13:45
知ったか乙

179:デフォルトの名無しさん
09/02/09 02:08:35
>>176
それはrubyやrailsが凄いのではなくて、後輩が凄いんだろう。
というか、作ったものの規模にもよるんだけど、たぶん君が極端に情けない。

180:デフォルトの名無しさん
09/02/09 06:19:23
>>176
３日で作るのが難しいようなプラグインだったのか？

181:デフォルトの名無しさん
09/02/09 17:09:16
javaしか知らないやつの言うことだぞ、分かるだろ

182:デフォルトの名無しさん
09/02/09 17:14:16
何年か前の15分でブログを作るってデモを思い出すなぁ
知らない人間にとっては確かに衝撃的だった

183:デフォルトの名無しさん
09/02/09 20:27:22
オレは、rails がいまだに何なのか知らない。ｗ

184:デフォルトの名無しさん
09/02/09 20:30:53
>>183
WEB用途を主なターゲットにし、DBとの連携も手厚くサポートしているフルスタックのフレームワーク、でいいのかな
使ってみればいいよ。・・・うかつにインストールしようとするとサーバ固まるけどな。

185:デフォルトの名無しさん
09/02/09 20:35:21
rails1.0以前に研究室の先生に言われていじってたけど
最初の一歩はかるーく大きく踏み出せるんだけど、込み入ったことを
やりだすと自分でCGIを一から書いた方が早かったという・・

今は情報もふえてそうでもないんだろうけど。

186:デフォルトの名無しさん
09/02/09 21:10:26
>>185
込み入っていない大多数の場合を対象にしているのがrails

187:デフォルトの名無しさん
09/02/09 21:31:02
>>185
いまでもそうだよ

188:デフォルトの名無しさん
09/02/09 21:32:14
「Railを外れる」といいます

189:デフォルトの名無しさん
09/02/09 21:38:36
てか「フレームワーク」だということを意識しないて使って投げちゃう人いるよね
"CGI" を1個か2個作る程度ならむしろRailsの学習は損で、個別に作ったほうがお得だ

設計上似通った感じのものをいくつも作るような人が、
その似通った途中経過をざっくり省略するために使うのがフレームワークであり、
Ruby理解者に向けたWeb上での小箸ｷ中規模アプリサポートプログラムがRails

190:デフォルトの名無しさん
09/02/09 22:36:30
Redmineてどーよ？

191:デフォルトの名無しさん
09/02/09 22:38:05
それが問題追跡システムの出来の事をいってるなら、結構いいよ
Rubyの開発・サポート体制の事を言ってるなら、知らね

192:デフォルトの名無しさん
09/02/10 03:44:45
　ちょっと他のスレッドで発見したのですが
　　　　　↓
ラーメンタイマーでも作ってみれ。
カップヌードル用(3分)とどんべい用(5分)に分ける。
できればタスクバーに駐在する奴。

こういうのってRubyでもサクっと作れますか？
できればexe化したもの

193:デフォルトの名無しさん
09/02/10 04:07:31
>>192
Rubyの仕事ではないと考える
っていうか、作ったとしても中身の95パーセントくらいはRubyではないな

194:デフォルトの名無しさん
09/02/10 04:16:16
VB2005スレの話題じゃん
「Rubyでは作れない」でいいと思う

195:デフォルトの名無しさん
09/02/10 07:29:11
vrubyで簡単に作れる

196:デフォルトの名無しさん
09/02/10 08:02:22
>>192
WxRuby使えばサクっとできる。たぶん他のGUIツールキットでもすぐできるだろう
タスクバー駐在のところは出来るかどうか解らないが

197:デフォルトの名無しさん
09/02/10 08:03:26
>>192
Shoesを使うという手もある。
URLﾘﾝｸ(the-shoebox.org)
URLﾘﾝｸ(whytheluckystiff.net)
URLﾘﾝｸ(shoooes.net)
URLﾘﾝｸ(sourceforge.jp)

198:デフォルトの名無しさん
09/02/10 09:12:52
おまいらそんなレスでお茶を濁していていいのか
Pythonスレでも見て来い

199:デフォルトの名無しさん
09/02/10 09:50:44
>>198
標準でできないことはRubyで無理してやれって言わないのがRubyのジャスティスって今決めた

ていうかPythonはGUIサポートがまともだから比較すらできんぞ
RubyのこのへんはどっちかってとPerlとかに近い

200:デフォルトの名無しさん
09/02/10 10:28:46
RUbyはexe化でも結構悩む死ね

201:デフォルトの名無しさん
09/02/10 10:37:26
>>191
手厳しいな

だがそれがいい!

202:デフォルトの名無しさん
09/02/10 20:08:34
Shoesいいな

203:デフォルトの名無しさん
09/02/10 20:55:10
ソース散らばるのがいやならコンパイラ言語使えばいいじゃん。あとHSPとか。
インタプリタ言語でexe化とか矛盾してるでしょ。

204:デフォルトの名無しさん
09/02/10 20:58:03
んなこたない

205:デフォルトの名無しさん
09/02/10 21:02:35
矛盾はしてない。
ただRubyでやるには整備不足というだけで。

206:デフォルトの名無しさん
09/02/10 21:27:02
スクリプト言語に何でもやらせすぎだよ。
本質はテキスト整形言語だぜ？
ちゃんとしたアプリは横着せずCやVBで作ろうぜ。

207:デフォルトの名無しさん
09/02/10 21:36:44
超簡易ラーメンタイマがちゃんとしたアプリってのもｗ
exe化する一番大きいメリットは多分、、Rubyが入ってないマシン（普通は入ってない）に
持っていっても使えるツールになることだと思う

208:デフォルトの名無しさん
09/02/10 21:39:15
>>206
C言語やVBにこだわりすぎだよ。
ちゃんとしたアプリだからといって思考停止せずスクリプト言語で作ろうぜ。

209:デフォルトの名無しさん
09/02/10 21:42:33
Cで細かい文字列処理をするのがめんどくさい

210:デフォルトの名無しさん
09/02/10 21:43:08
ここら辺はC#やDelphiでやるのが手っ取り早いよ。
タイマーといえども作りこむと結構な大作になるしな。

211:デフォルトの名無しさん
09/02/10 21:46:29
.NET Frameworkが必要です。＞C#
Rubyで作れば作り方次第ではLinuxにも持って行けるよ！いけるよ！タスクトレイってなに？！

誰もJavaって言い出さないのが素敵だ。

212:デフォルトの名無しさん
09/02/10 21:51:48
Javaのクライアントアプリなんて総じて糞だからな。
それしかないって時以外は絶対に使わない。

213:デフォルトの名無しさん
09/02/10 21:52:59
.NET Framework上でもRuby動くよ。
C#で作っても作り方次第ではLinuxにも持っていけるよ。Gnomeのタスクトレイ(相当)もOK。

214:デフォルトの名無しさん
09/02/10 21:53:05
メイン環境がLinux, GNOMEなのでRuby/Gtk2でいい感じに

215:デフォルトの名無しさん
09/02/10 22:29:35
ウィンドウとか作るのはRubyの仕事ではないとみなしていいと思う
タスクトレイ云々はあれはたまたまウィンドウ出てないだけで内部的にはウィンドウだし

216:デフォルトの名無しさん
09/02/10 22:56:50
しかし敢えてHaskellを使う

217:デフォルトの名無しさん
09/02/10 23:47:33
ところで、普通は「駐在」じゃなくて「常駐」って言わないか？

218:デフォルトの名無しさん
09/02/10 23:56:33
ひょっとするとSwingスレにいた奴かもな。ヒマなやつだ

219:デフォルトの名無しさん
09/02/11 05:18:04
SWTも思い出してあげてください

220:デフォルトの名無しさん
09/02/11 05:47:30
SWTってeclipseの？

221:デフォルトの名無しさん
09/02/11 06:42:03
ここのところずっとsocketがいじられてるねえ

222:デフォルトの名無しさん
09/02/11 09:09:29
>>219
>SWTも思い出してあげてください
AWT(Abstract Window Toolkit) の間違いじゃなくて？

223:デフォルトの名無しさん
09/02/11 13:58:25
デビアン前提の言語だしなあ。窓はサポート外。

224:デフォルトの名無しさん
09/02/11 14:09:25
誰もサポートの話なんかしてないよ

225:デフォルトの名無しさん
09/02/11 14:18:38
>>192
Pythonスレ荒らしてたのお前か

226:デフォルトの名無しさん
09/02/11 16:34:35
プレゼンテーションしたい人どうぞ

日本Ruby会議2009
URLﾘﾝｸ(rubykaigi.org)

227:デフォルトの名無しさん
09/02/11 23:32:26
オナテーションっすかｗ

228:デフォルトの名無しさん
09/02/11 23:48:15
>>227
？

229:デフォルトの名無しさん
09/02/12 00:39:34
>>227
？

230:デフォルトの名無しさん
09/02/12 01:07:16
>>227
？

231:デフォルトの名無しさん
09/02/12 01:12:23
>>227
？？

232:デフォルトの名無しさん
09/02/12 06:13:28
松本教祖様への忠誠を示す集会か。信者どもは、しっかり寄付しろよ。

233:デフォルトの名無しさん
09/02/12 06:22:17
URLﾘﾝｸ(jp.rubyist.net)
概出？

234:デフォルトの名無しさん
09/02/12 09:53:27
世界的に普及しつつある？

北米などの2倍以上に：新興市場で輝きを放つRuby
URLﾘﾝｸ(www.itmedia.co.jp)

235:デフォルトの名無しさん
09/02/12 09:58:58
>>234
もともとRubyのシェアは少ないからな
使いたい一部の人に広まり切っただけで数字上は拡大になるぞ

236:デフォルトの名無しさん
09/02/12 10:10:26
>>233
残念だががいしゅつ（>>145）
たぶんURLが書かれてなかったから、検索しても見つからなかったのだろう

237:デフォルトの名無しさん
09/02/12 10:13:03
GUIだとShoesが一番人気なんだな。知らなかった

238:デフォルトの名無しさん
09/02/12 10:27:42
一番人気というか、面白そうなので注目中ってとこだね

239:デフォルトの名無しさん
09/02/12 13:05:55
Rubyプログラマの3分の2はRubyでGUIプログラミングの経験あり　日本で最も人気のあるツールキットは「Ruby-GNOME」
URLﾘﾝｸ(codezine.jp)

240:デフォルトの名無しさん
09/02/12 13:32:03
ひどいタイトルだなあ。

241:デフォルトの名無しさん
09/02/12 15:28:19
ネタ投下
URLﾘﾝｸ(www.sssg.org)

242:デフォルトの名無しさん
09/02/12 19:10:43
経験はあるけどみんな挫折したってことだよね
rubyのGUIツールがほとんどないって事実が物語ってる。
一方pythonはGNU/Linuxにおけるシステム/GUIツールの地位を不動にしたよね
俺もDbus呼ぶプログラムとかがんがん書いてるし。つまり、Rubyは日本人による
オープンソースへの貢献をさまたげてるってことか・・・・

243:デフォルトの名無しさん
09/02/12 19:31:45
＞一方pythonはGNU/Linuxにおけるシステム/GUIツールの地位を不動にしたよね
いや、それは初耳だ

244:デフォルトの名無しさん
09/02/12 19:35:54
相手にするな
どうせPythonユーザの間でも煙たがられてるさ

245:デフォルトの名無しさん
09/02/12 19:55:33
アナコンダとyumあたりのことを言っているのでは

246:デフォルトの名無しさん
09/02/12 20:03:09
>Rubyは日本人によるオープンソースへの貢献をさまたげてるってことか・・・・

正しいとは思えんけど
あながち否定できんな

247:デフォルトの名無しさん
09/02/12 20:29:41
真面目に考えると
Ruby製のGUIアプリケーションってほとんど見たことない……なんでだろう

それとも、見たことないのは俺が見つけてないだけで
実際には色々なアプリケーションがあったりする？

248:デフォルトの名無しさん
09/02/12 20:30:58
rabbitはたまに使う

249:デフォルトの名無しさん
09/02/12 20:33:20
漏れは自分で使うプログラムはRuby-Gnome2でGUI作ってるわ

250:デフォルトの名無しさん
09/02/12 20:56:44
大半の用途じゃCUIでも困らないような
Ruby版Delphiみたいなのが登場すれば使うかも

251:249
09/02/12 20:59:19
>>250
Linuxでしっくりくる画像ビューアがなかったので作った。
たしかに大半はCUIでいけるね。

252:デフォルトの名無しさん
09/02/12 21:10:38
>>250
他のツールキットは知らないけど、QtでDesignerとか使えばほぼそれに近くないかな？

253:デフォルトの名無しさん
09/02/12 21:41:53
$ apt-cache rdepends python-gtk2 | wc
270 271 3845
$ apt-cache rdepends ruby-gnome2 | wc
3 4 51

圧倒的じゃないか

254:デフォルトの名無しさん
09/02/12 22:08:57
% apt-cache rdepends libgtk2-perl|wc
48 49 790
＿|￣|○

255:デフォルトの名無しさん
09/02/12 22:10:32
$ apt-cache rdepends libgtk2-ruby|wc
15 16 218

情報操作はやめなさい>>253

256:デフォルトの名無しさん
09/02/12 22:12:39
大して変わらんとか

257:デフォルトの名無しさん
09/02/12 22:19:56
これってシステムやらウインドウマネージャ周辺のツールをpythonで統一してるだけでしょ
まあ、それを差し引いてもrubyの方が少ないとは思うけどさ

258:デフォルトの名無しさん
09/02/12 22:50:16
「だけ」っていうか、それも違いのうちだろ

259:デフォルトの名無しさん
09/02/12 23:02:37
ディストリビューション提供のツールだから別のディストリには入ってないって事
*BSDや別のディストリで調べたらこんな桁違いの差は出ないだろ

260:デフォルトの名無しさん
09/02/12 23:05:50
ディストリ限定であっても，どんだけ採用されてるか，どんだけ使われてるか，ってのは気になるところでしょ
ライブラリとかは豊富で便利になってくれたほうがいいし

261:デフォルトの名無しさん
09/02/12 23:05:55
潔く負けを認められない人たちばかりなんですね

262:デフォルトの名無しさん
09/02/12 23:18:45
勝ち負けはどうでもいい。負けてるのは分かりきってるから
というわけで、関心が集まるのは内実

263:デフォルトの名無しさん
09/02/12 23:21:20
勝ち負けは基本的にどうでもいいんだけどPythonの人はこのスレに来て何をしたいの？
新規ユーザーをrubyに取られるのが怖いの？ネガティブキャンペーンてやつ？

264:デフォルトの名無しさん
09/02/12 23:34:08
疑問はもっともだが安心して。
PythonスレでもRubyをダシにして同じ様なことが繰り返されているのだから。

265:デフォルトの名無しさん
09/02/12 23:34:49
>>263
荒しは失せろ

266:デフォルトの名無しさん
09/02/12 23:50:45
kita2はruby製

267:デフォルトの名無しさん
09/02/13 01:02:26
べつに Python > Ruby ということが言いたい訳じゃないんだよね
Python ユーザーは普及がどうたらこうたら気にしないのに
Ruby ユーザーはやたら普及度を気にしてると
このスレを見てて思う

268:デフォルトの名無しさん
09/02/13 01:11:31
>>267
それはPythonがかなり普及してるからだ！

269:デフォルトの名無しさん
09/02/13 01:12:23
なんつうか愉快犯っぽい中学生が双方のスレに出没してるな

270:デフォルトの名無しさん
09/02/13 01:16:42
単に春厨がわいてるだけでしょ
Linux板でもほとんど同じやりとりを見たよ。言語を使用するって行為には参加できないけど
人気合戦なら簡単に誰でも参加できるからね。VIPでやってる茸vs.竹の子みたいなものだから
無視すればいいだけと思うよ。

ところで、ChangeLogのForzenっていつ見ても笑えるね。いつ直されるかなw

271:デフォルトの名無しさん
09/02/13 01:23:50
pythonのスレいくつか見てきたけどrubyのスレよりひどいね
技術的な話には食いついて来ないから 267 みたいな対立煽りかな

272:デフォルトの名無しさん
09/02/13 03:34:16
Matzは、もう青い鳥を追い求めるような泥沼開発をやめ、
仕様を固定したうえでバグ取りと高速化とドキュメント整備に専念すべき。
でないとRubyはbrainfuckレベルの趣味的言語で終わる。
それでいいと言うなら構わないが、ならばIT業界を巻き込むのはやめてくれ。

273:デフォルトの名無しさん
09/02/13 04:02:54
本人に言え

274:デフォルトの名無しさん
09/02/13 04:08:34
>>273
>>272

275:デフォルトの名無しさん
09/02/13 04:10:09
巻き込まれるのは弱小IT会社だけ。
スマートなやつはRubyでばんばんアプリをつくるし
大規模Webサイトも構築して巨万の富を得ている。

速くて仕様が決まっててお役所並の文書がある言語しかつかえない
カスグラマはJava/C#を使って代替可能なコマになればいいだろう

276:デフォルトの名無しさん
09/02/13 04:25:41
>>272
教授「皆勝手にそっちから関わって来たんだ」

277:デフォルトの名無しさん
09/02/13 12:13:20
IT業界を巻き込んでるのはMatz本人じゃなくて
そこに群がる金目当てのとりまき連中だろ

278:デフォルトの名無しさん
09/02/13 20:11:39
あーあの会社とかあの会社とかか。

279:デフォルトの名無しさん
09/02/13 20:18:05
RubyなのにJavaの4文字があったら緊急回避の印

280:デフォルトの名無しさん
09/02/14 00:10:52
Net::HTTPHeader#add_field(key,val) って確か、
既存のヘッダがあればその値の末尾にセミコロンつきで val を追加するよね
これってどんなときに嬉しいの？
末尾に追加されるより先頭に挿入してもらったほうが嬉しくね？

281:デフォルトの名無しさん
09/02/14 03:04:26
railsを一からじっくり勉強し直したいんだけど良い書籍が見つからない。

●RailsによるアジャイルWebアプリケーション開発第2版
これはいくら内容良くてもバージョンが１．２だから論外
●Railsレシピブック
これは使い方は分かってもRailsの勉強にはならない…もっと実装の奥を知りたい
●実践Rails（オライリー）
本屋で立ち読みしたけど、これは既にRailsを良く分かってる人が読む本だと思うので除外

他にも色々見たけど見つからない。皆どうやって勉強してるの？

282:デフォルトの名無しさん
09/02/14 05:10:59
>>281
> もっと実装の奥を知りたい
つ　ソース

283:デフォルトの名無しさん
09/02/14 07:03:04
意味わからん。
フレームワークは使ってナンボ。
実装の中身を知る必要はない。

284:デフォルトの名無しさん
09/02/14 07:16:14
>>283
実装の奥と実装の中身の違いを説明してくれ

285:デフォルトの名無しさん
09/02/14 07:52:15
つまらんこと聞くな。
とにかく>>281は言っていることがおかしい。
Railsの使い方を勉強してるヤツはゴマンといるが、
実装を勉強してるヤツなんかいない。

286:デフォルトの名無しさん
09/02/14 08:04:48
言い切ったｗ

287:デフォルトの名無しさん
09/02/14 08:12:40
それこそ個人でソース読めソース読めないような人間は要らんで終了ではある
研究してる人間がいないとは言わないが、他人向けに解説するような人がいるとは思えないし、
Railsに限っては解説を受けたからってよりうまく使えるようになるとも思えねー

288:デフォルトの名無しさん
09/02/14 08:39:54
実装を知りたいんじゃなく、実装のその奥を知りたいんだろ。
つまり思想だな。
Matzの啓蒙書でも呼んどけ。

289:デフォルトの名無しさん
09/02/14 08:41:26
DHHじゃないの？

290:デフォルトの名無しさん
09/02/14 08:41:49
Railsはまつもとゆきは無関係だな

291:デフォルトの名無しさん
09/02/14 08:43:26
そうでした。

292:デフォルトの名無しさん
09/02/14 08:44:14
>>290
ホントは嫌いなんじゃないかと思うことはある

293:デフォルトの名無しさん
09/02/14 08:45:19
>>292
Rails を好きな Rubist なんていません！！！

294:デフォルトの名無しさん
09/02/14 08:56:07
Railsのコピーを作りたいとか

295:デフォルトの名無しさん
09/02/14 08:56:32
まあ、DSLの勉強をしたいのかなとはちょっと思った

296:デフォルトの名無しさん
09/02/14 10:59:09
Ruby開発陣がほとんどRails使ってないのは常識。

297:デフォルトの名無しさん
09/02/14 11:41:04
ちょっとMatzに会ってくる

298:デフォルトの名無しさん
09/02/14 11:42:32
いってらっしゃい

299:デフォルトの名無しさん
09/02/14 12:07:34
>>281
秀和のRuby on Rails入門は？
アマゾンのレビューで叩かれている理由がわからんが

次ページ