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」ってハンガリアン記法の問題そのままだなｗ
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といい、一応ファーストクラスオブジェクトなのに
そのへんの仕様で足引っ張ってる感じだｗ
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
オレはずっと１Ｆだったが、ささだ研がブラック研究室ということが分かったよかったｗ
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
バズワードだってｗ
使ってみたかったんだねｗ
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>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:デフォルトの名無しさん
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>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:デフォルトの名無しさん
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>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" "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
>漏れなくは無理でも、実際に数えてみたら無視出来る程度の数だったりしてな。
この手の問題は、数が少ないからといって無視できるものではない。
というより、データ変換については間違いがあってはならないのが前提であり、
すこしでも間違いがあれば大きな問題。
１文字でもうまくいかないのがあれば、移行しない人が大勢いても不思議ではない。
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
必要に応じてうだうだ追加してきただけの既存規格が
もうそんなに文化的なものになってるのかｗ
って、もとから超人工的で場当たり的なものなんだからそれはねーよ
、とマジレスｽﾏｿ
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
> 必要に応じてうだうだ追加してきただけの既存規格が
> もうそんなに文化的なものになってるのかｗ
>>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 だったからといっていい方向に作用したと思われるものではない、はず
375:デフォルトの名無しさん
09/07/26 11:15:43
URLﾘﾝｸ(d.hatena.ne.jp)
ヒドスwww
376:デフォルトの名無しさん
09/07/26 16:42:35
ささぴーひっどーぉい。（か☆わ★い☆い★女☆子★高☆生 より
377:デフォルトの名無しさん
09/07/26 17:06:50
うわぁ
378:デフォルトの名無しさん
09/07/26 19:52:21
おいtrunkのrakeやrdocやrubygemsは最新版にアップデートしないのか
379:デフォルトの名無しさん
09/07/26 20:11:05
ruby-coreでいえ
380:デフォルトの名無しさん
09/07/26 21:03:56
アップデートしてくれる度にtest-allのエラー数が激増するんで困ってる
381:デフォルトの名無しさん
09/07/27 11:34:32
> Google App EngineではJRails on Rubyも動いてます。
> もうJVMでいいじゃんっていうことになる危機感は？
ここはまつもとさんじゃなく、
ささださんの回答が見たかった。
382:デフォルトの名無しさん
09/07/27 13:42:39
bigtableは独特だからなぁ
383:デフォルトの名無しさん
09/07/27 14:31:58
ここに書けばささださんの回答は得られる
384:デフォルトの名無しさん
09/07/27 14:59:14
Rails で web アプリケーションをやろうとしていて、
1.9 系はまだ使いたくないという場合は、1.8.7 を選んでおけばいいのでしょうか？
385:デフォルトの名無しさん
09/07/27 15:02:50
あい
「一般ユーザー」でRuby1.9を現在使うメリットとデメリットを均すとマイナスになります
エラーの意味も原因もさっぱりわからん直せと言われてもさっぱり、な人はしばらく 1.8.7 で待機しましょう
386:デフォルトの名無しさん
09/07/27 15:16:21
自力で改修くらいできるぜﾋｬｯﾊｰという人はガンガン 1.9.1 を使って欲しいところ
汎用性があったらライブラリ作者に連絡でもしてくれ
387:デフォルトの名無しさん
09/07/27 15:19:38
そんな人が何人いるんだよ…
388:デフォルトの名無しさん
09/07/27 15:47:28
改修くらいはできるけど
あえて1.9.1以降を、自分から積極的に使う意欲はわかない
389:デフォルトの名無しさん
09/07/27 15:48:51
github になったら commit する人とか少し出るかも
390:デフォルトの名無しさん
09/07/27 17:22:17
ちょっとだけ違う野良フォーク祭りになるだけのような気がしなくもないが、
ブログとかに差分がちょこっと書かれてるだけとかいうのよりは遥かにマシか
391:デフォルトの名無しさん
09/07/27 18:06:17
なにをどうすれば pull request に足るものなのかよくわかんないんだよね
だったら自分専用でいっかーみたいな
392:デフォルトの名無しさん
09/07/27 18:08:36
そういう混沌状態を意図してるのでないの？
思いっきりforkやcommitの敷居を下げることでさ
393:デフォルトの名無しさん
09/07/27 19:12:31
パッチが欲しいからgithubに行くと言ってる人がいるとするならば、
その日とは「なんでもいいからpull requestしろや、俺が全部
さばいてやるぜ」というつもりで言ってるんだよね？
394:デフォルトの名無しさん
09/07/27 19:46:47
githubになったって、そこ巡回してpullするリソースがないよ。
現状、Redmineに上がっているパッチだって取り込まれるのに時間かかってるのに。
あと、そんなパッチもtypoの修正ならともかく、たいていはそのままじゃ取り込めない。
395:デフォルトの名無しさん
09/07/27 21:20:40
じゃあ、githubに移行するという話は根拠のないデマなの？
396:デフォルトの名無しさん
09/07/27 21:24:00
githubに移行して欲しいと言う人たちはいる。
また、githubに公式リポジトリのミラーを置く計画はある、こちらはyuguiさんのリソース次第
397:デフォルトの名無しさん
09/07/27 21:25:43
とはいえ、今より敷居が下がるのはいいことだとおもうけどね
なんか今だと関連MLの記事を数年分把握してて、
主要コミッタとのリアルつきあいも欠かさず行って、
一日の何時間かをRubyに捧げる宣言しないとならなくて、
事情があっても辞めるに辞められないようなイメージがあるわw
398:デフォルトの名無しさん
09/07/27 21:59:12
>>397
それ全部満たしてる開発者いないだろｗ
399:デフォルトの名無しさん
09/07/27 22:39:26
WindowsのMingw版rubyを1.8.7にバージョンアップしたら
Thread.new{system 'ruby -e sleep(30)'}
が、負荷10数%食うようになってた orz
Mingw版 1.8.6 とか 1.9.1だとそんなことは無いし
Mswin版 1.8.7 で試しても問題なかったのでMingw版1.8.7だけなのかも
STDIN.getsがスレッドを止めなくなったとかの影響なんだろうか
とりあえず、ちょっとだけ待ってスレッドを殺すことにした
1.9だとspawn使えるんだけど
400:デフォルトの名無しさん
09/07/27 22:55:00
それはまつもとさんでもあやしいなぁ……ｗ
401:デフォルトの名無しさん
09/07/27 23:48:33
URLﾘﾝｸ(www.atmarkit.co.jp)
なにポーズつけてるんだよ（ｗ
402:デフォルトの名無しさん
09/07/27 23:51:46
これは三つ子と言われても普通に信じるレベル
403:デフォルトの名無しさん
09/07/27 23:58:35
yugui さんにしろ笹田さんにしろ、若いのにすごいなぁっておもった。
おれなんか33の業務系SEだけど、
Ruby にしてもほかの言語にしても、使う側で精一杯だよ。
こういう人たちは、「プログラミング言語オタク」でもあるんだろうな。
404:デフォルトの名無しさん
09/07/28 00:31:24
>>403
人のことを素直にすごいと思えるおまいさんはまだ伸びる素質がある。
なにかにつけ欠点を探して自分を優位にしておかないと気が済まない連中というのが少なからず存在して、
そういうやつは口ばっかり達者でいつまでたっても実力が身につかない。
405:403
09/07/28 01:39:13
>>404
どうもありがとう、コーディングする機会も減ってきたが、まだまだがんばるよ。
406:デフォルトの名無しさん
09/07/28 02:17:08
>>404
でも、いろんな人やら意見を懐疑的に捉えて自分なりに
いろいろ考えるのも楽しいお。
盲目的に「すげー」はかえって学ぶ機会を損失するとおも。
407:デフォルトの名無しさん
09/07/28 07:41:54
何事もバランスが大事
408:デフォルトの名無しさん
09/07/28 08:16:52
>>401
これ新宿駅の紀ノ国屋のところのウッドデッキかな?
409:デフォルトの名無しさん
09/07/28 09:26:57
rubygemsのライブラリをpull requestするときは、せめて
git pull git://pull先の人のmaster target_branch
git checkout target_branch
git rebaseまたはmerge my_branch
testrb1.8 test/
testrb1.9 test/
rake
rake1.9
gem1.8 build
gem1.9 build
の最後の7つを通してからにして欲しい
稀～に、pull先の人の公開masterの時点でrake全然通んねとか腐った状況もあるが
410:デフォルトの名無しさん
09/07/28 10:10:21
>>408
秋葉原のUDX1Fのテラス(タリーズ)じゃないの？
411:デフォルトの名無しさん
09/07/28 11:28:55
>>408
Matzの左上に高架線の架線柱が見えるけど、
新宿のウッドデッキは、そこより高い位置に線路はない。
412:デフォルトの名無しさん
09/07/28 13:24:17
なるほど。たしかにささだ氏のホームグラウンド的にもそっちだね。
413:デフォルトの名無しさん
09/07/28 13:29:53
>>409
なんかめんどくさッ！
414:デフォルトの名無しさん
09/07/28 13:41:41
だからgithub持ってくのには消極的反対なんだよ
415:デフォルトの名無しさん
09/07/28 13:48:18
何を言う、コード追加・変更の説得力のベースになるものが
一連の手続きとして試行可能だなんて鼻血が出るほど素晴らし過ぎるじゃないか
これが問題なく終わってれば後は口頭で説得するだけだろ？
最悪取り込まれなくても、「動作可能・動作検証可能」なコードとして存在できる
メーリングリストのどっかにちょろっと書かれたのを個々人が実行、なんてのよりはるかにマシ
めんどくさいというそれそのものには大きく同意はする
でも、githubで公開する時にだけやればいいだけだしさー
pushの前に一連の検証すればとりあえずオッケー、というのだけで安心感違うだろ
416:デフォルトの名無しさん
09/07/28 13:57:01
>>397
> なんか今だと関連MLの記事を数年分把握してて、
十回くらい上がるたびに同じような理由で却下されたような提案を、また得意
顔して出してくるやつがいたら、誰だってうんざりするだろ。
> 主要コミッタとのリアルつきあいも欠かさず行って、
不要。tsなんて誰も顔も知らなかった。
> 一日の何時間かをRubyに捧げる宣言しないとならなくて、
宣言なんて無意味。自分が必要だと思ったことをすればいいだけ。
> 事情があっても辞めるに辞められないようなイメージがあるわw
正直いってライブラリとか新規プラットフォームとかは、追加したはいいけど
後は知らんぷりで全然メンテしてくれなくなっちゃって困りまくり、という例
も多々あるので、継続できないのなら無理に入れてほしくない。
417:デフォルトの名無しさん
09/07/28 14:13:25
ライブラリや新規プラットフォームは、
メンテナと「サブメンテナ」を用意しないと対応しない、でもいいと思う。
もちろん「サブメンテナ」も活動しなくなる可能性はあるけど
少しだけフェイルセーフ。
418:デフォルトの名無しさん
09/07/28 14:14:49
メンテナを抜ける場合は別のメンテナ1人かサブメンテナ3人を紹介しないと抜けられないというのはどうだろう
419:デフォルトの名無しさん
09/07/28 14:18:02
ああっ、教祖や経典を崇める感じでシューキョーっぽかったRubyがとうとうマルチに手を
420:デフォルトの名無しさん
09/07/28 14:19:38
いいね。
あとブログや twitter なりでライブラリ保守されていないから改良した、
野良パッチをあてた、と書いている人を「スカウト」する積極さがあってもいいかも。
421:デフォルトの名無しさん
09/07/28 15:04:51
必要なのは優秀なコード書きじゃない
有象無象を束ねる優秀なマネージャー
まーつまりあれだ、いつも会社でウンザリしながらやってることを、
レベルも認識もバラバラの目の前にいない素人混じりの大人数に対して
金銭的報酬もないまま本来余暇であるはずの時間をつぎ込んで捌くような人が必要だということだ
422:デフォルトの名無しさん
09/07/28 15:12:12
>> 事情があっても辞めるに辞められないようなイメージがあるわw
>正直いってライブラリとか新規プラットフォームとかは、追加したはいいけど
>後は知らんぷりで全然メンテしてくれなくなっちゃって困りまくり、という例
>も多々あるので、継続できないのなら無理に入れてほしくない。
Rubyの内部事情ってそんなに酷いん？
423:デフォルトの名無しさん
09/07/28 15:18:34
ここ数年の Ruby の(リリース)マネージャは個人的には疑問だなぁ。
もっとアジャイルなほうがいいと感じてる。
優秀なコーダなんだから、
マネージャはモチベーションを上げたりするような
ファシリテータやコーチ的なのが合う気がする。
なんだか古臭いマネージングな気がして。
424:デフォルトの名無しさん
09/07/28 15:19:40
真の人柱だな…
425:デフォルトの名無しさん
09/07/28 15:34:36
>>422
Rubyの開発しやすさ、Rubyの中ではなんでもできる、作ってて超楽しい、というのが
物理的に広い開発では極めて悪い方向に作用している
これまで破綻しなかったのはそれこそ教祖様の数多の一声（の、却下）があってこそ
426:デフォルトの名無しさん
09/07/28 15:38:45
誰もやりたがらないことは
やらずに放っとけばいいよ
そのうち誰かがやってくれるから
これが Ruby クオリティ
427:デフォルトの名無しさん
09/07/28 16:43:24
tsって誰
428:デフォルトの名無しさん
09/07/28 16:54:40
>>425
Ruby標準・添付ライブラリが比較的マトモで、Railsがおおむねカオスなのはまつゆきの存在が大きい
Rubyからまつゆきを取り除くと、たぶんRailsになる
429:デフォルトの名無しさん
09/07/28 18:27:01
コントロールブレイク ネタにマジレスしているakrたんに萌えた。
430:デフォルトの名無しさん
09/07/28 18:33:34
> あとブログや twitter なりでライブラリ保守されていないから改良した、
> 野良パッチをあてた、と書いている人を「スカウト」する積極さがあってもいいかも。
blogやtwitterに書きっぱなし、野良パッチ当てっぱなしの人をスカウトすると、
結果がどうなるかは、まぁ、目に見えてますよね、そういうのはいやなんだ。
一方で、ruby-devにパッチ投げまくってくる人とか、IRCでパッチ書いてる人とかは、
誘ったりしてるよ。
> ここ数年の Ruby の(リリース)マネージャは個人的には疑問だなぁ。
それ以前の惨状をご存じの上で仰っておられるのでしょうか・・・。
まぁ、外から見ていると印象は違うかもしれない。
というか、coreの人間はtrunkしか見てないんで、リリース直前でもない限り、
リリースマネージメントはあんまり関係ないよ。
むしろそんな調子なのでちゃんとリリースマネージメントをやってくれる人がいないと、
いつまでたってもリリースできないんだ。
>>425
> Rubyの開発しやすさ、Rubyの中ではなんでもできる、作ってて超楽しい、というのが
> 物理的に広い開発では極めて悪い方向に作用している
Rubyと言っても、>>416のライブラリってのは標準添付な拡張ライブラリだろうから、
ソースは基本的にCだよ、Ruby使えるから素より遙かに楽だけど。
まぁ、そういういくつかのライブラリでの話であって、
全体的にそこまでの惨事になっているわけではないのでご安心ください。
>>428
あと、akrさんの存在もかなり大きいと思う。
431:デフォルトの名無しさん
09/07/28 18:51:43
そもそも、今までのコミッタってどうやってコミッタになってるの？
誰かに推薦されたとかそんな感じ？
どういう形でコミッタになったのか、ということと、コミッタになった後
どんな活動を続けているかand/or続けなくなってるか、ということって、
それなりに相関があるんじゃないかと思うんだけど、どうかな？
432:デフォルトの名無しさん
09/07/28 18:55:43
「惨状」とは思わなかったなぁ。
今は締切までに機能追加が間に合わないと、
次のリリースまで待たないといけなくてイマイチ。
期日の厳守のしすぎは目的と手段を見失っている感じ。
あと「惨状」とか「優秀なマネージャ」とか主観が強すぎ。
433:デフォルトの名無しさん
09/07/28 19:48:55
>>430
だからまあ、パッチの都合がよければpull requestを受け入れて、悪ければスルー。以上終了、って感じの
ゆるくて敷居の低いアプローチが求められてるんじゃね。
散々既出のネタに対して過去ログ嫁だのFAQ嫁だのレスしたりFAQ整備したりする必要はなくなるから。
どうせ何かの案が採用される率なんて手法に依らず千三つみたいなもんなんだから
却下がノーコストで提案の母数が増えるならそっちの方がよかろうと。
434:デフォルトの名無しさん
09/07/28 20:08:43
BTS使っているから、何度も寄せられる要望を抽出して、そこを見ろ、でもいいと思うし。
435:デフォルトの名無しさん
09/07/28 23:48:36
おお、Yuguiさん乙だ
自身のブログでgemの多言語化について詳細に書いてる。アクセス集まってるのか心なしか重い。
そういやRubyKaigiまだ見てないな・・・。
436:デフォルトの名無しさん
09/07/28 23:49:41
1.9系の話ね。
437:デフォルトの名無しさん
09/07/29 00:02:05
って一週間前に書いてるじゃん
なんで気づいてなかったんだ俺
438:デフォルトの名無しさん
09/07/29 00:12:05
漏れはとりあえずマニュアル整備してくれてる方々に最大の賛辞を送りたい
439:デフォルトの名無しさん
09/07/29 08:58:31
>>431
ざっとIRCでアンケートを取ったところ(IRCにいるということは現在アクティブであると推察される)、
パッチを投げてたら釣られた人と、立候補が半々くらいだった。
あとは、coreをいじる人とライブラリメンテナでは違いがあって、
ライブラリの場合はある程度完成しちゃうとそれ以降いじらなくなる人がいるかな。
最近ライブラリの追加に否定的な人が多いのはこの辺の事情も影響してる。
440:デフォルトの名無しさん
09/07/29 09:10:28
はッはッはッ、安定したライブラリに手を入れる必要なんてどこにあるんですカ
441:デフォルトの名無しさん
09/07/29 09:13:23
>>423
そうやってexperimentalな機能をとりこみ続けるとカオスになる。
今まで以上にいつまでも安定しない処理系を使ってもらえるか疑問。
ただし、とにかく色々出してみて有用なのを取り込んで安定させるというスタイルに向けて舵を切るべく、その意味でもgit化は期待できる。早くやれ。
個別の機能については「これは重要だから仕様凍結を破れ」と意見すれば受理される余地はある。
だから、メーリングリストで取り入れるべきだと主張すればいい。メーリングリストの敷居が高ければtwitterだっていい。
442:デフォルトの名無しさん
09/07/29 10:09:19
> blogやtwitterに書きっぱなし、野良パッチ当てっぱなしの人をスカウトすると、
> 結果がどうなるかは、まぁ、目に見えてますよね、そういうのはいやなんだ。
443:デフォルトの名無しさん
09/07/29 10:27:17
Rubyにしろなんにしろ属人的なものは減らしていかないと逝けないの鴨知れない
Matzだっていつまでも生きていられる訳じゃないんだし
444:デフォルトの名無しさん
09/07/29 10:33:55
個人の才能による作品を認めない優秀なマネージャ
445:デフォルトの名無しさん
09/07/29 10:35:32
芸術作品を日常使うと不便というのはよくある話
コルビジェの作った建築も雨漏りがしたっていうし
446:デフォルトの名無しさん
09/07/29 10:38:18
>>444
信念を持ってリジェクトできることこそが、マネージャーとして優秀である証
それがすばらしい作品であることと、それを取り込んだものがすばらしくなるかどうかは別
447:デフォルトの名無しさん
09/07/29 10:40:14
コンテストじゃないんだから勘弁してくれ
448:デフォルトの名無しさん
09/07/29 11:02:37
人間としても成熟してこそ優秀なマネージャ
449:デフォルトの名無しさん
09/07/29 11:59:51
>>439
すると、後は非アクティブな人のうち、パッチを投げて釣られた人・立候補した人の比率がどうかを見るといいんでしょうか？
ところでIRCでアンケート取ったとかいうことは、あなたは中の人ですか？
450:デフォルトの名無しさん
09/07/29 12:23:49
そういえば、一応すでにgithubにリポジトリのミラーはあるよ
URLﾘﾝｸ(github.com)
pushとかpull requestとかはできないけど
>>449
非アクティブな人にはアンケートという技が使えないので、MLあさらないといけないんですよね。
「SSH鍵」とかのキーワードで探せばいいと思うんだけど。
URLﾘﾝｸ(jp.rubyist.net) ちなみにIRCってのはこれ
451:デフォルトの名無しさん
09/07/29 12:24:15
アンケートを取ったのが中の人かどうかが何にどう関係するのかがわからない
452:デフォルトの名無しさん
09/07/29 12:29:51
>>440
> はッはッはッ、安定したライブラリに手を入れる必要なんてどこにあるんですカ
典型的なのはバグ報告が来た場合、セキュリティ絡みだととっても困る。
あとは本体の仕様変更に追従すべき場合、たとえばM17Nですね。
453:デフォルトの名無しさん
09/07/29 12:35:28
それくらいならそのコード読めばだいたい修正個所はわかるんじゃね
作成した人しかコードが触れないという呪いでもかかってるわけじゃなかろう
そのライブラリと分野のプロフェショノー（滑らかな発音）を一人は置く状態にしておく、というのもわかるが
でもそれだと修正要求に応じられるだけのバックグラウンド知識がライブラリメンテナに要求されるな
454:デフォルトの名無しさん
09/07/29 12:40:28
まーそりゃ本体組み込みや添付のライブラリは基本的なライブラリが多い（ことが期待される）から、
ライブラリのメンテナーの知識レベルは高いほうがいいと思う
ネットアクセスライブラリ作ったけど HTTP の知識よくわかんないどうすればいいかな、ではやっぱ困る
せめて、それなりに自分ひとりで意見組み立てた上で他の人のアドバイス募る、くらいでないと
455:デフォルトの名無しさん
09/07/29 12:43:20
>>453
URLﾘﾝｸ(www.ruby-lang.org)
こういうのが来て、メンテナと連絡がつかなかったらどうする？
456:デフォルトの名無しさん
09/07/29 12:52:50
些細な変更でも、誰がそれをやるかって言うのはあるな。
457:デフォルトの名無しさん
09/07/29 12:56:19
>>455
いやだから、rexml のソースは読めるだろ
初心者には無理だが、中級者かそれ以上なら首っ引きでなんとでもなるだろ
普段のだらだらした新機能要求ならまだしも、セキュリティバグなら「誰かできる人」がやるべきだろ
たとえば、「メンテナが学会出張中なのでそれが終わってからゼロデイ脆弱性のパッチをリリースします」でいいのか？
458:デフォルトの名無しさん
09/07/29 13:19:27
いいんじゃねえの
メンテナーの責任ってそういうことだろ
459:デフォルトの名無しさん
09/07/29 13:22:01
てか、そもそも、作成者が対応する義理も義務も何もないんだぜ
使って不都合なら、使用者側でなんとかするか、問題のないものに切り替えるべき
460:デフォルトの名無しさん
09/07/29 13:26:41
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
から始まるスレッドにも情報があるんだが、
このREXMLのDOS脆弱性は以下のような悪条件が揃っていた事例であった。
1. セキュリティ絡みのバグ
2. メンテナと連絡がつかない
3. 根本的な解決にはAPIの変更が必要
このため、当初はモンキーパッチを公開し、議論の上で根本的な解決を入れることになった。
議論はruby-dev, ruby-core, 非公開のセキュリティMLで行われた。
議論の結果、REXML::Document.entity_expansion_limitという新APIが追加された。
先述の通りメンテナ不在であったため、これらは前田さんによって行われた。
461:デフォルトの名無しさん
09/07/29 13:28:58
なぜ対応するかというと、はっきり言えば矜持なんだろう
「この状況はマズい」と感じて、「なんとかしないといけないものだ」と考えるから
じゃあ、みんなでよってたかってやればいいんじゃねーの、と思う
緊急用待機のメンテナーなんてなくてもいい
ライブラリ新機能更新用のメンテナーと、みんなが読み解けるように維持されたコード、この2つでたぶん充分だ
462:デフォルトの名無しさん
09/07/29 13:49:33
>>461
> じゃあ、みんなでよってたかってやればいいんじゃねーの、と思う
だめな例としてセキュリティインシデントが挙げられたんだと思うけど
> ライブラリ新機能更新用のメンテナーと、
> みんなが読み解けるように維持されたコード、この2つでたぶん充分だ
パッチ取り込みのコストを過小評価してないかなぁ。
というか、とりあえず誰か先に出てたgithubのミラーをベースに、
Redmineに上がっているバグを修正し、githubにupして、メールベースでpull希望だしてみたら。
463:デフォルトの名無しさん
09/07/29 13:54:42
仕事でRuby使っても大丈夫かどうか不安になってきました
464:デフォルトの名無しさん
09/07/29 14:01:41
誰かメンテナがいたとして、その人が修正コードを出してきたとしても、
「よっしゃ○○さん仕事早ええじゃあ早速コミットします」
じゃないだろやっぱ
それなりに複数の人が検証時間取ったり実はそれほどとってなかったりするだろ
じゃあやっぱ他の人が適当に修正コードらしきもの作ってもそれなりに検証されたりするんじゃね
メンテナのコードなら間違わない可能性が高いというのなら、そもそもバグは起こってないはずでさ
465:デフォルトの名無しさん
09/07/29 14:07:15
>>464
ヒント: メンテナにはコミット権がある
466:デフォルトの名無しさん
09/07/29 14:31:25
もともと、リリースがらみの仕事はまつもとさんに集中していた。
しかし、Rubyも1.8になるとライブラリの肥大化と安定性への期待が高まってきた。
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.2 リリース前
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.3
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.3^preview1予告
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.3-preview1
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.3でやっちまった例(logger)
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.4
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.4
URLﾘﾝｸ(blade.nagaokaut.ac.jp) 1.8.5
特にリリースエンジニアリングが重要な課題だと認識されたのは、
1.8.3において、リリース直前のloggerに対する変更が原因で、
リリース版の1.8.3でRailsが動作しなかったことではなかろうか。
これにより、リリース直前の機能変更の危険性が開発陣で認知されることとなり、
仕様凍結の必要性が叫ばれることとなった。
その後、1.8.4や1.8.5において、凍結を実施してみたところ、
その感想はおおむね「多少マシになったけどまだダメ」といったところであった。
467:デフォルトの名無しさん
09/07/29 14:39:36
schedule for Ruby 1.8.6
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
1.8.6ではいくつかの大きな変更が行われた。
1つは武者さんのリリースマネージャの就任である。
これは、まつもとさんが1.9への変更に専念できると同時に、
まつもとさんやその他のcore開発者の1.8からの隔離を意味していた。
これにより、1.8系は格段に安定性を増すことが可能となった。
もう1つは卜部さんの安定版メンテナの就任とパッチリリースの導入である。
従来のRubyは、
1. 十分な機能追加があった場合
2. 大きなバグの修正があった場合
にリリースが行われていた。
しかし、これだと特定のバージョン+バグの修正という安定性を重視した
構成をとりづらいというデメリットがあった。
他にも、仕様凍結と併せてブランチを切ることで不要な変更の混入を抑止したり、
さらに長くした凍結期間といった、細かな変更も行われている。
これらの施策によりRuby 1.8.6は「最初のまともな安定版」となることができ、
1.8.6は高い評価を得ることとなった。
468:デフォルトの名無しさん
09/07/29 15:16:19
>>459
実際そういう考えが主流だった時代もあったけど、
今時それはよくないよね、って考えで
かつ実際血を流して対応してくれる人が出てきてくれた御陰で
Rubyは-pxxxのセキュリティパッチ適用リリースが出るように
なったわけで。
そうなるまでは機能追加とセキュリティパッチは
ごちゃ混ぜでリリースされてたわけで。
今考えるとすごい状況だよな
469:デフォルトの名無しさん
09/07/29 15:26:01
github は一度 push したブランチが訂正できないから嫌い
git に「ハッシュ値を変更せずにコミット内容だけ訂正する」みたいなオプションがあればいいのに
470:デフォルトの名無しさん
09/07/29 16:40:07
>>464
もうちょっと地に足をつけた上で提案としてまとめたほうがいいんじゃないかな
それぞれの場面で実際に誰が動くのか、動かなかった場合どうするのか考えないと、
話は進まないよ。
たとえばマスターはsvnのままという前提で行くと、pull requestされたパッチを、
どうやってgitの世界からsvnの世界へと持っていくか、とか。
471:デフォルトの名無しさん
09/07/29 18:14:35
>>469
お前さん、「ハッシュ値」って意味わかっていってる?
それが簡単にできたら、gitの前提が崩れさるだけじゃなく、
セキュリティ的に大騒動が起きるんだが。
472:デフォルトの名無しさん
09/07/29 22:56:33
>>451
答えてくれて嬉しいんだけど、この親切で素敵な人はいったいどこの誰だろう、という私の好奇心が満たされる。
473:デフォルトの名無しさん
09/07/29 23:04:36
>>457
そうだな、中級者かそれ以上なら誰でも直せるかもしれないな。
だから、誰だかわからんけど「誰かできる人」が直してくれるはずだから、
それまで放っておけばいいよな。
と、いうことになったら永久に誰も直さないかもしれないから、最終的には
責任を負うべき「メンテナー」というものが存在してるわけだろ？
474:デフォルトの名無しさん
09/07/30 02:21:46
>>473
まさにそういうことです。
で、メンテナ不在のライブラリは結構すでに多くて、
URLﾘﾝｸ(redmine.ruby-lang.org)
のうち、noneに加えて、まつもとさんと中田さんがメンテナになってるのは、
事実上メンテナがいないのものです。
また、メンテナがアクティブでないものは、why、serのと青木さんのかな。
前田さんのもほとんどメンテナンスされてないかも。
475:デフォルトの名無しさん
09/07/30 02:57:17
層の薄さが
476:デフォルトの名無しさん
09/07/30 04:52:54
>>473
わかってないんだな
どうして緊急性のあるものと緊急性のないものをわざと混同して話すんだ？
477:デフォルトの名無しさん
09/07/30 05:01:59
>>476
Redmineを見れば緊急性のないものがいくつか放置されているのが見て取れると思うんだけど
478:デフォルトの名無しさん
09/07/30 10:43:33
>>476
だから、
緊急性があるかどうかを判断して、
影響範囲を検討して、
修正を行って、
というのを誰がやることになるのかが問題だ、つってんだろ。
479:デフォルトの名無しさん
09/07/30 11:02:25
「緊急度が低い用件」という、何がしかの判断が済んでいるシロモノがあるように見えるのが間違いだな
判断されてるならそれに任せればいいという話にしかならん
「緊急なのか危険なのか誰にも全く判断されずに転がってる要件がいくつもあります」でなければならない
480:デフォルトの名無しさん
09/07/30 11:02:53
メンテナがいなかったり動いていない場合はとりあえず中田さんに振る、
というのが現状なんだが、遅かれ早かれ限界は来る
481:デフォルトの名無しさん
09/07/30 11:06:34
>>479
バグ報告の時点で重要度とか優先度とかあるのおかしいと思うんだ、俺
482:デフォルトの名無しさん
09/07/30 11:08:11
Rubyの赤は中田さんの血の赤というわけか
483:デフォルトの名無しさん
09/07/30 11:21:03
>>481
理想と現実の区別はしような
484:デフォルトの名無しさん
09/07/30 13:21:53
>>481
別に報告者の考えるそれがあるのはおかしくないじゃん
それらは必要なら受付者が変更するものなわけだし
485:デフォルトの名無しさん
09/07/30 14:14:32
本当は、報告されてきたバグや要望を、重要度や優先度をつけつつ担当者に割り振る、
Redmineマネージャみたいな人が必要なんだよね。
486:デフォルトの名無しさん
09/07/30 15:12:37
おまえらその議論の情熱を１０％でもコードにぶつければだな
487:デフォルトの名無しさん
09/07/30 15:21:06
そりゃただの逃避だ
我々に必要なのは神業コードでも大量データでもない
488:デフォルトの名無しさん
09/07/30 15:24:28
そーだな
「オレたちにできるのは愚直にコードを書き続けることだけだ！」
でできたのが山のような未管理のコードとライブラリ
現実見ようぜ現実
489:デフォルトの名無しさん
09/07/30 15:27:27
まぁ、この一連の議論で一人くらいは釣れないかなぁと思っているわけです。
* 新しく登録されるバグを誰かに押し付けるだけのお仕事
(誰に押し付けるかで半年ROMる必要があるか)
* 登録されたバグの中から簡単そうなのを見つけてパッチを作るだけのお仕事
(最初はお作法にあってないとかで、せっかく書いたパッチを書き直されるかもしれないけどめげない)
* 英語のわけのわからん機能追加に対して「何寝言言ってるんだバカ」と英語で答えるだけのお仕事
とかが君を待ってるぜ
490:デフォルトの名無しさん
09/07/30 15:31:54
抜けるときに10人生け贄、もとい後継者を紹介するみたいな闇ルールがなければ......
実は>>489も後継者探しなのではと疑ってしまう猜疑心の強い俺
491:デフォルトの名無しさん
09/07/30 15:39:34
特にどこかメンテナンスする義務を負わないように逃げまくって、
気の向いたときに気の向いたところを直すとかにすれば大丈夫だよ。
492:デフォルトの名無しさん
09/07/30 15:53:30
>>420
> あとブログや twitter なりでライブラリ保守されていないから改良した、
> 野良パッチをあてた、と書いている人を「スカウト」する積極さがあってもいいかも。
それやると、みんな沈黙するという結果に至る。
493:デフォルトの名無しさん
09/07/30 16:27:23
メンテナーがメンテナンスで食っていけないかぎり、この問題は解決しないのでは？
494:デフォルトの名無しさん
09/07/30 16:29:19
なんらかの報酬か褒賞か報奨はあってもいいかなとも思うが、そんなんないのが普通だよなとも思う
すぱっしょさんくすに本名載せたるから名刺代わりに使え、というのが限界かと(w
495:デフォルトの名無しさん
09/07/30 16:45:11
Ruby会議を利益が出るようにして、メンテナーに配分とか。
496:デフォルトの名無しさん
09/07/30 16:46:31
税金でメンテナーの給料を出す様に民主党のマニフェストに入れて貰うとか。
497:デフォルトの名無しさん
09/07/30 17:13:53
>>492
> blogやtwitterに書きっぱなし、野良パッチ当てっぱなしの人をスカウトすると、
> 結果がどうなるかは、まぁ、目に見えてますよね、そういうのはいやなんだ。
の発言のほうが沈黙するだろｗ
こんなの書いててすみません、みたいな。
498:デフォルトの名無しさん
09/07/30 17:38:44
やっぱり金だよな
499:デフォルトの名無しさん
09/07/30 18:03:34
Rubyビジネスなんとかで金出して優秀なマネージャをフルタイムで雇えばいいじゃん。
500:デフォルトの名無しさん
09/07/30 18:22:14
他のオープンソースプロジェクトって、どうやって回してるんだろう
501:デフォルトの名無しさん
09/07/30 18:33:17
>>494
> なんらかの報酬か褒賞か報奨はあってもいいかなとも思うが、そんなんないのが普通だよなとも思う
報酬をもらわないうちは、これの価値は無限大と思っていられる。
報酬なんか出したら、みんな手を出さなくなってしまう。
502:デフォルトの名無しさん
09/07/30 18:35:39
>>494
> すぱっしょさんくすに本名載せたるから名刺代わりに使え、というのが限界かと(w
ぼくの知覚圏内では、パッチ送って「ぼくの名前出さないで」な人は結構多いん
だが、Ruby宇宙ではそんなことないのか?
503:デフォルトの名無しさん
09/07/30 18:40:07
見返りが欲しい人は名前載せてもいいよそれくらいしかできないよ、という話かと
名前別にいらない、という人は少なくないな
504:デフォルトの名無しさん
09/07/30 18:58:59
>>501
誰もメンテナンスしていないライブラリ群をメンテナンスするには、フルタイムのメンテナーがいないと厳しい。
505:デフォルトの名無しさん
09/07/30 19:00:14
そんなことよりまあ聞いてくれよ、github で公開されてるライブラリをてきとうにフォークして、
それなりに分類になってるブランチを3つくらいいろいろコミットして push したら、
「Network」のとこの自分のアカウントのところがめっちゃ太く長く横に伸びてて凄く恥ずかしいんだが
うん、いや、それだけ
よく考えたらフォークした結果を push して公開する意味ってあまりないよね
自分でだけ使ってりゃ充分だもんな