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 して公開する意味ってあまりないよね
自分でだけ使ってりゃ充分だもんな
506:デフォルトの名無しさん
09/07/30 19:08:02
>>504
Rubyでニート脱出のフルタイム在宅ワークがあります
（中級程度のCとRubyの知識があり各種ネットプロトコルとソケットを低レベルで理解しLinuxプログラミングとライブラリ作成の経験があって大規模ソース管理への造詣もある場合は業務未経験でも大歓迎！）
と煽るのはどうだろう
507:デフォルトの名無しさん
09/07/30 19:28:23
>>504
>>501はトンチンカンだった。ありゃ開発者のことだな。
メンテナはどっかのオプソ系会社の社員が仕事でやってても
おかしくはないな。
508:デフォルトの名無しさん
09/07/30 19:31:39
>>506
Rubyの求人ってそんなんばっかだよな
注釈や他の要件が長くて、しかもそっちが必須
だったら最初からRubyって書かないほうがスキルの高い人集まるだろうに
509:デフォルトの名無しさん
09/07/30 19:38:03
TTYとRUBYって似てるよね
510:デフォルトの名無しさん
09/07/30 20:38:34
>>508
「Ruby」って書くと、「注釈や他の要件に書かれた事柄を一人でできる人」って意味になる
511:デフォルトの名無しさん
09/07/30 20:41:02
Ruby1.9.1 のこないだ出たやつを Ubuntu にインストールしようと思ったんだけど、
なんか configure に必要なオプションってある？
だいぶ前に p0 のをインストールしたときは readline とか openssl とか指定しないといけなかった気がしたんだけど、
まだ自動で探さない？
512:デフォルトの名無しさん
09/07/30 21:49:30
Firefoxは、右上の検索バーで収益を上げているみたいだけど、Rubyも
何かできないかな？
MLに広告を載せるとか、www.ruby-lang.org/に広告のせるとか。
ユーザの負担にならない程度に、収益を上げる方法を考えるべきでは？
あまり広告主の影響受けるのも良くないけど。
現状は収益源って何かあるの？
513:デフォルトの名無しさん
09/07/30 21:58:40
>>512
誰の?
514:デフォルトの名無しさん
09/07/30 22:08:01
カッコイイ人が多いイメージのある県ランキング
URLﾘﾝｸ(ranking.goo.ne.jp)
515:デフォルトの名無しさん
09/07/30 22:11:37
>>492
それはやっぱり抜けるときのルールが不明確だからじゃね?
「どうやったら足抜け出来るかわからない」世界に飛び込むのって命がけじゃん。
特に期待されてるような「責任感の強い人」ほど責任が全うできるかわからなくて
二の足を踏むのでは?
例えば任期を一年単位にしてみるとかさー。
516:512
09/07/30 22:29:05
誰の収益源かというと、何と言っていいのか分からないけど、Rubyのメンテ
ナンスをしている人達、そのチームとしての収益なんだけど。
現状は収益0円？ だとすると、PCの電気代がかかるんで、むしろ
個人でお金を払ってメンテナンスしているんですかね。
517:512
09/07/30 22:36:58
メンテナ募金というか、寄付を募集するのも、まずいんですかね。
アメリカは、寄付の文化がありそうなので、Rubyなら集まりそうな
気もするけど。
フルタイムで働く賃金が出せなくても、足しになればいいのでは。
518:デフォルトの名無しさん
09/07/30 22:41:09
yes
519:デフォルトの名無しさん
09/07/30 22:49:54
BSD系とかだと寄付を受け付けてるし
OpenBSDはネットで入手できるものと中身は同じと断った上で
リリースのパッケージ売ったり、Ｔシャツ売ったりしてるな。
あっちはフルタイムの開発者もいるしセキュリティオフィサーもいるなあ。
フルタイムって意味ではぶっちゃけJRuby界隈に頼んだら受けてくれそうな気もするけど、
企業リソースに致命的なパートを依存すると完全にキンタマ握られかねなくて
頼むに頼めないってのもあるか。
520:デフォルトの名無しさん
09/07/30 22:55:12
Runyってオスだったのか
521:デフォルトの名無しさん
09/07/30 22:55:14
なにより、「フォークは自由だがRuby自体は俺のもんだ」って教祖様が常々
おっしゃってるので、組織的な動きがしにくいってのもあるんじゃね？
522:デフォルトの名無しさん
09/07/30 22:56:52
向かうところ敵なしの勢いのCPAN界はどうなってるよの。
523:デフォルトの名無しさん
09/07/30 23:00:20
>>517
一応Ruby Associationってのがあるんだけど、個人宛だとお金の配分とか受け渡しとかが面倒なんだよね。
個人的にはコンパイルファームが欲しいんだけど、まぁそれの管理者も必要になってしまうので云々。
ちなみにWebサーバやリポジトリ用のマシンは今NaCl持ちかな。
いきなりメンテナだと感じもわからないだろうので、まずはIRCから始めてみると、
コミッタの生態もつかめてよろしいかと思います
524:デフォルトの名無しさん
09/07/30 23:02:27
>>517
開発の仕事で食ってるサラリーマンからすると、たまに中途半端な金なんか
渡されても嬉しくもなんともない。
金が関わらないから、遊びという名目で仕事の外で付き合っていられるんで
あって、プロに金渡すなら、労力に見合った額をきっちり出してもらわんと困る。
>>519
Engine Yardという会社が、しばらく前からruby 1.8.6の保守を担当しているよ。
フルタイムの従業員を一人そのために割り当てている。
525:517
09/07/30 23:14:16
なるほど。確かに、仕事で開発している人なら、金とは関わりない世界で
携わりたいのは理解できる。
人手が足りなくて負担になってるみたいなんで、書き込んでみたんだけど。
私が少し考えて解決策がでるぐらいなら、もともと問題になってないよなあ。
526:デフォルトの名無しさん
09/07/30 23:15:36
>>524
技術の安売りはしない。これはあくまで仲間内/趣味での話
......って整理をしてるケースは多いよね。
haunとかもそうだった気がする。
527:デフォルトの名無しさん
09/07/30 23:19:17
>>525
いやその前に、あんたが何を「問題」視してるのかがわからんと話にもならん
RubyはRubyでそれなりの発展を（まだ）続けているし、ここまで来たらたぶん
Matz（やひょっとしてささださん）一人になっても、本人らが飽きず・食えてる
限りはそれなりに続くだろう
528:525
09/07/30 23:29:37
問題っていうのは、489の書き込みのように、人手が足りないこと。
人手を確保するにはお金じゃないの？という議論があったんで。
私は、「金が関わらない世界で遊びでやりたい」という気持ちを理解して
いなかったんで、的外れなことを言って申し訳ない。
529:デフォルトの名無しさん
09/07/30 23:34:35
>>528
そこは統一見解ではないというかインナーサークルと外側とで見解が違ったりするんじゃない?
あと金にしても端金なのか契約の元普通に人を雇える額なのかでも違ってくると思う。
実際未踏のお金(国からの補助金)でYARVは開発されてたわけだし。
530:デフォルトの名無しさん
09/07/30 23:39:51
>>526
「技術の安売りはしない」なんていう高尚な話じゃないんだ。
フルタイムの本業を持ってるメンテナがいて、本業が忙しく
なってRubyに手を出す時間が取れなくなったとする。
この場合、そのメンテナ個人にちょっと金を渡しても、問題は
全く解決しない。
個人が金を貰っても本業の忙しさには何の影響もないんだから。
メンテナの時間を確保するためには、そのメンテナが本業の
代わりにRubyをいじれるだけの金を出す、つまりフルタイムで
雇用してやるか、または、メンテナの所属する会社に適切な
代金を払ってメンテナの時間を買うか、どちらかしかない。
531:デフォルトの名無しさん
09/07/30 23:40:46
基本、締め切り付きで何かのアウトプットを求めるなら、
善意へ期待じゃなくて何らかの代価を払うべきとは思うけどね。
それこそセキュリティパッチみたいに「気が向いたら」だとマズいようなケースもあるし
そこぐらいはフルタイムの担当を雇いつつ代価を求めてもいいと思うけどね。
まあ陳腐な例だけどそれこそＴシャツ売るでもいいわけだから。
532:デフォルトの名無しさん
09/07/30 23:43:20
問題はだ。フルタイムで誰ならおまいら納得するんだと。
おまいらが期待するような人材は、大概他でバリバリやってるんだってば。
今のところmatzがフルタイムぽいんだが不満なのか？
533:デフォルトの名無しさん
09/07/30 23:46:21
>>528
「金が関わらない世界で遊びでやりたい」と言ってる
わけではなくて、「遊び」という形で背負える程度の
責任しか背負いようがないだけ。
個人に小銭を渡しても、使える時間が増えるわけじゃ
ないんだから、背負える責任の大きさは変わらない。
だから、使える時間を増やせるほどの額じゃなければ
受け取るわけにはいかないのだ。
534:デフォルトの名無しさん
09/07/30 23:46:47
matzがフルタイムっぽいのは理解したうえで、さらに人手を増やすには
どうしたらいいか、という話じゃないの。
matzが健在ならオールオッケイなのか？
535:デフォルトの名無しさん
09/07/30 23:48:29
じゃあどこまで規模を広げるべきか、そういう話になるはずだよな。
なってるか？
金があるから大きくなるんじゃなくて、大きくするために金が必要
ってのが普通の流れだよ。
536:デフォルトの名無しさん
09/07/30 23:51:27
何かアプリ作れよ。世界中で使われればRubyに興味を持つやつが増える。
ビジネス的な価値を見いだすところが出れば金が集まる可能性も高まる。
537:デフォルトの名無しさん
09/07/30 23:52:50
どこまで人を貼り付けないとマズいのか、ってところだよな。
1.8.6にフルタイムで人が貼り付いてるのは多分Rails関連でしょ?
あとはサポート継続中のリリースに対してセキュリティ対処出来る分だけの
リソースがあるなら当面はいいんじゃないかなと思うけど。
538:デフォルトの名無しさん
09/07/30 23:54:51
matzは布教活動で忙しいんだよ。
539:デフォルトの名無しさん
09/07/31 00:09:56
>>536
Tracの前にRedmineが作られていれば、キラーアプリになれたかもね。
MovableTypeと同等のRuby製品があって、ちょっとだけ早く出ていれば、
Rubyの方がレンタルサーバで優遇されたかもね。
PHP5と同時期にmod_rubyというか、mod_railsがあれば、そっちにも
人は流れたかもね。インストールの手間は大して変わらんし。
結局、Rubyは何かを作ってきた、世の中を動かして来たって実績がほとんど無いんだ。
常にアンチテーゼを提出してみるだけの文化が染みついてるんだ。
万年野党もいいじゃないか
（って感じで関わる人間が多い気もするんだ実際）
540:デフォルトの名無しさん
09/07/31 00:13:33
>>532
matzはコミット権の剥奪を申し渡されるようなタイプだから、
仕様策定者、開発者としてはともかく、保守担当者としては
完全に役者不足。
541:デフォルトの名無しさん
09/07/31 00:20:20
向き不向きってのはあるからね
ある意味フルタイムで雇っているなら自分の思いと求められていることとが
相反したときでも契約をよりどころに割り切って行動できるかもしれないけど、
その辺ナシで自分の思いと反する行動をとるって負担度が高いよね。
542:デフォルトの名無しさん
09/07/31 00:27:46
>>527
実際のところ、開発に関しては放っておいても全然問題は
ないだろうね。
今まで同様、なんとなく続いていくだろう。
問題は、何度も出ているように、保守。
543:デフォルトの名無しさん
09/07/31 00:37:10
>>539
portupgradeとかtDiaryとか。
まぁ、Rubyは世界を変えるためのものじゃなくて自分の日常をちょっと便利にするためのものなんで、(Railsは知らんよ)
そういう意識の人は多いかもね。
544:デフォルトの名無しさん
09/07/31 00:38:32
>>539
Tracのお陰でpython人口が増えたとも思えない。敢えてrailsをキラーアプリと言わないのも意味不明。
今せっかくRubyの人気が世界中で高まってきているところで、ライブラリ1.9への対応という難題が上がってきていて、今までの様になんとなく誰かがやるのを待つっていうのは、評判を悪くすることになりはしないか？
野党でもいいというのは、他の言語もバリバリできるできる人の発想。凡人は、特化することによってしか活路はない。matzは凡人用のlispとしてRubyを作ったと言ったら、穿ちすぎ？
545:デフォルトの名無しさん
09/07/31 01:09:23
なるほど、こういう人たちがいるがために今の状況があるわけか
546:デフォルトの名無しさん
09/07/31 01:21:50
>>544
Railsは実際に依存している1.8.6がRails関連の金で保守されてるからでしょ。
悪く言えばそこでもう切り離されちゃってる。
547:デフォルトの名無しさん
09/07/31 06:42:33
結局、保守担当者として1人フルタイマーが必要ということ？
Railsが1.9に依存するようになれば、企業が、保守担当者（保守のみ）の
人件費を負担してくれるようになるかな。
548:デフォルトの名無しさん
09/07/31 07:41:39
国がΣプロジェクトに費やしたお金を考えると、メンテナーの二人や三人を税金で賄ってもどうってことはない。
549:デフォルトの名無しさん
09/07/31 08:04:28
Rubyが未踏に選ばれたのは「国産だから」だよね
550:デフォルトの名無しさん
09/07/31 08:11:57
>>548
今まで浪費してきたんだから次の浪費も許されるべきだ、
なんて論法だと身代が潰れるぞ
せめてこうこうこういう理由で必要だから、って言い方にしないと
551:デフォルトの名無しさん
09/07/31 08:26:32
>>549
選ばれる以前の話で、未踏の応募資格は日本人または在日であること
552:デフォルトの名無しさん
09/07/31 08:28:39
>>551
？
553:デフォルトの名無しさん
09/07/31 08:59:38
>>550
済まん。余計な事を書いた。
あの無駄になった２００億以上のお金の何分の一でもあればな～とつい思ってしまった。
KAMEプロジェクトのように、国際貢献になるから、予算つけてくれないかなと思わざるを得ない。
554:デフォルトの名無しさん
09/07/31 09:08:11
そしてgoogleからの圧力によりスーパー301条の対象に。
555:デフォルトの名無しさん
09/07/31 10:10:54
やっぱりお金と人を投入すれば
速くなって使いやすくなって
JavaやPerlやPHPを駆逐していくんだらうか
556:デフォルトの名無しさん
09/07/31 10:18:45
原理的にそれほど速くはならんだろ
そりゃ歴代Rubyの中ではどんどん速くなるだろうが、JavaやPerlにはもともと敵わない
てきとーに作られた中規模Javaプログラムは、必死でチューニングした中規模Rubyスクリプトよりもたいてい速い
応答速度が速いほうがいいプログラムの需要はどうあっても尽きないから、駆逐は無理だ
Rubyスクリプトが高速に動作する環境を用意した場合、他の言語のプログラムは爆速で動く
というわけで、ハードウェア大国日本の面目躍如としてRuby専用CPUの開発をだな
557:デフォルトの名無しさん
09/07/31 10:21:51
YARVチップですか
558:デフォルトの名無しさん
09/07/31 10:33:10
>>556
そういう姑息な真似をしないとPerlより速くならないRubyはクズ
まで読んだ
559:556
09/07/31 10:34:34
>>557
YARVって何？
560:デフォルトの名無しさん
09/07/31 10:46:53
>>559
血税を投入してJRubyより劣った仕組み
561:デフォルトの名無しさん
09/07/31 10:53:02
スピードなんていらない。使いやすければそれでいい。
早いプログラムがほしけりゃFortranで書いてスパコンで実行させるからさ。
欲しいのはパパッと書けて１０秒ぐらいで忘れられるコードだよ。
ただ、rubygemsはno-rdoc no-riをつけないと遅くてたまらん。ああいうところは
改善しないのかな
562:デフォルトの名無しさん
09/07/31 11:02:23
rubygem 開発陣のマシンが超パワフルなので問題ありません
563:デフォルトの名無しさん
09/07/31 11:02:37
>>560=本物の>>556乙
564:デフォルトの名無しさん
09/07/31 11:06:05
>>562
バージョン 0.x 時代の YAML 展開ハングアップのことまだ根に持ってるのか(w
565:デフォルトの名無しさん
09/07/31 11:25:14
シェフのまかないつきRubyエンジニア求人来た！これで勝つる！
URLﾘﾝｸ(headlines.yahoo.co.jp)
566:デフォルトの名無しさん
09/07/31 11:36:05
>>564
Debianユーザにとっては笑えない…こないだのlennyリリースまでずーっとこの問題抱えざるを得なかったから
567:デフォルトの名無しさん
09/07/31 11:57:09
バイト列自体が文字エンコーディング ENC である ASCII_8BIT のでっかい文字列があって、
このでっかい文字列のエンコーディング情報はとりあえず変換したくないという場合、
特定の文字列の正規表現をマッチさせたい場合って
/#{"特定の文字列".toENC.force_encoding(::Encoding::ASCII_8BIT)}/ =~ ASCII_8BIT文字列
か
/#{"特定の文字列".toENC}/ =~ ASCII_8BIT文字列.dup.force_encoding(::Encoding::ENC)
のどっちかしかない？
568:デフォルトの名無しさん
09/07/31 12:10:09
>>567
後者しかない
569:デフォルトの名無しさん
09/07/31 12:18:50
前者もエンコーディングが合ってるからマッチはするはず
irb> /#{'わんわんお'.force_encoding(Encoding::ASCII_8BIT)}/ =~ 'わんわんわんお'.force_encoding(Encoding::ASCII_8BIT)
6
570:デフォルトの名無しさん
09/07/31 12:24:26
/#{'好'.encode("EUC-JP").force_encoding(Encoding::ASCII_8BIT)}/ =~
'テスト'.encode("EUC-JP").force_encoding(Encoding::ASCII_8BIT)
ダメな例
571:デフォルトの名無しさん
09/07/31 12:26:52
ていうか、実は両方ダメ
/#{'表'.encode("sjis").force_encoding(Encoding::ASCII_8BIT)}/ =~
'表'.encode("sjis").force_encoding(Encoding::ASCII_8BIT)
572:デフォルトの名無しさん
09/07/31 12:30:43
というわけで、正答例
src="テスト"; pat="好"; enc="euc-jp"
/#{Regexp.escape(pat.encode(enc).force_encoding(Encoding::ASCII_8BIT))}/ =~
pat.encode(enc).force_encoding(Encoding::ASCII_8BIT)
573:デフォルトの名無しさん
09/07/31 12:45:30
あ、うん、ここだけ前時代的問題が噴出するよね
# -*- coding: utf-8 -*-
require 'open-uri'
uri = "ｽﾚﾘﾝｸ(tech板:571番)n"
html = open(uri).read
p /#{"表".encode(Encoding::SJIS)}/ =~ html rescue puts $!
p /#{"表".encode(Encoding::SJIS).force_encoding(Encoding::ASCII_8BIT)}/ =~ html rescue puts $!
p /#{"表".encode(Encoding::SJIS)}/ =~ html.dup.force_encoding(Encoding::SJIS) rescue puts $!
動作しそうな記述のうちで実際にマッチするのは最後だけというのがなんとも
incompatible encoding regexp match (Shift_JIS regexp with ASCII-8BIT string)
too short escape sequence
1732
574:デフォルトの名無しさん
09/07/31 13:04:53
CSIだからJavaみたいにユニコードリテラル表現を用意しておいて
最悪ファイル上の非ASCII文字列はnative2asciiつかうって逃げ道も美しくないしなあ
575:デフォルトの名無しさん
09/07/31 13:07:06
外人さんって force_encoding と ASCII_8BIT 好きだよね
576:デフォルトの名無しさん
09/07/31 13:12:05
狂犬発動してUTF8をデフォルトエンコーディングにしておけばこんなことにはならなかったのに…
Windows憎しで避けてたらLinuxすら標準になっちゃったのにな。
577:デフォルトの名無しさん
09/07/31 13:13:39
WindowsではいまだシフトJISが通らないと困ることも多いだろ。
UTF-8で統一強行したらみんな不幸だわ。
578:デフォルトの名無しさん
09/07/31 13:19:44
>>576
Shift_JISのHTMLを読み込んだらUTF-8になってるってこと？
579:デフォルトの名無しさん
09/07/31 14:37:14
force_encoding ってバイト列のほうは変更しないから何度繰り返しても大丈夫だよね？
580:デフォルトの名無しさん
09/07/31 15:01:13
>>573
文字を文字として扱いたいときには、きちんとエンコーディングをつける。ただそれだけのこと。
バイナリとして操作したらはまるにきまってる。
>>576
そういう問題ではないと思うけど。
>>579
まぁ、そうだけど、なんで何度も繰り返したいの？
581:デフォルトの名無しさん
09/07/31 15:47:41
あ、1.9の話してる
クラス変数って継承されるの？ 継承されないの？
582:デフォルトの名無しさん
09/07/31 15:57:32
全パターンありそうだな
URLﾘﾝｸ(www.google.com)
583:デフォルトの名無しさん
09/07/31 16:37:00
>>580
>まぁ、そうだけど、なんで何度も繰り返したいの？
繰り返したいんじゃなくて一回しか呼ばれないことを保証できないんじゃない?
ライブラリ的なものを作ってると悩むかもしれん。
584:デフォルトの名無しさん
09/07/31 16:53:27
>>581
される、でFA。
継承というのもまた違う気がするが。共有というべきかな。
585:デフォルトの名無しさん
09/07/31 17:17:09
>>582
どうしてこうなった…
586:デフォルトの名無しさん
09/07/31 17:55:50
あれ、「1.9ではクラス変数は継承されない」という説明があるのはなんで？
587:デフォルトの名無しさん
09/07/31 19:56:26
>>561
無理だろう
仮に、rubygems開発チームが改善する気になってくれたとしても
現時点でrdoc＆ri生成がデフォルトになってる以上、もうどうにもならんと思う
そもそも最初から、rdocとriの自動生成なんてやるべきではなかった
発想がいくらなんでも富豪的すぎる
588:デフォルトの名無しさん
09/07/31 21:37:42
URLﾘﾝｸ(shyouhei.tumblr.com)
gitktkr
589:デフォルトの名無しさん
09/07/31 22:55:02
ｷｬｰｼｮｳｻｰﾝ
これは抱かれてもいいレベル
590:デフォルトの名無しさん
09/07/31 23:10:48
30時間はすげーな、mput超乙
しかもこれから来るpull requestを全部捌くわけ？
591:デフォルトの名無しさん
09/07/31 23:17:08
さて、git.ruby-lang.orgへの移行はどれくらい先になるか
592:デフォルトの名無しさん
09/07/31 23:38:01
卜部おにーさんは格好良いなあ
593:デフォルトの名無しさん
09/08/01 05:24:25
>>587
それこそrubygems開発陣のマシンでは「ちょっと待つだけ」だったんだろうな
594:デフォルトの名無しさん
09/08/01 06:13:33
>>577
それはない
595:デフォルトの名無しさん
09/08/01 07:24:26
1.9.1で動いてたライブラリやスクリプトが1.9.2で動作しなくなる可能性って今のところどのくらいある？
596:デフォルトの名無しさん
09/08/01 07:40:25
1.9.1で動作してるなら「めったに無いんじゃないかなー」という程度
まだ仕様が固まったわけじゃないからはっきりとはなんとも
「1.9.2を見据えるとやらないほうがいい書き方」というのは今んとこ無いはず
597:デフォルトの名無しさん
09/08/01 10:44:17
そろそろ RAA for 1.9 作って未対応のものを締め出すのがいいと思うんだ
598:デフォルトの名無しさん
09/08/01 10:44:59
1.9系はスルーして2.0から使うのが本道
599:デフォルトの名無しさん
09/08/01 11:36:18
>>598
書き込むスレ間違えてますよ
ｽﾚﾘﾝｸ(tech板)
600:デフォルトの名無しさん
09/08/01 14:34:15
そろそろ移動
loopとtimesが似てるとは思わない、そもそもloopにカウンタがほしいとも思ってない
でもあれば便利ってのは理解できる
Kernel#loopが存在している上で新たにIntegerにメソッドを加えれば
単に「繰り返す」ではなく「（ある値から）数え上げながら処理を繰り返す」という意味になる（できる）し
それがtimesの「ある値まで数え上げながら処理を繰り返す」と対称だということ
（timesのメソッド名から考えれば「指定回数繰り返す」なんだけど、ブロック引数取った場合には）
つまり数値が始点か終点となるかの違い
ただ始点のデフォルトが0なのに対して終点のデフォルトは極大だから終わりがない
でもInteger#loopという名前は初めから微妙だと感じてるし
そのせいで批判されまくってるんじゃないかと
0.start {|i| puts i }
やっぱり名付けのセンスないな・・・
601:デフォルトの名無しさん
09/08/01 18:55:13
まあ1.9にしたい香具師ががんばって人柱に成ってれば良い。
それまで今までの互換が有る1.8使ってるから。
信者増やして金儲けしたいなら、リナックスVISAクレジットカードみたいにルビークレジットカードでも作ると良いのかもな。提携カードビジネスは儲かりそうだ。
どんどん宗教法人の様層を呈して来て、松本教祖に金が集まる仕組みに成って来たな。
602:デフォルトの名無しさん
09/08/01 19:00:51
nokogiri-1.3.3のtest配下に2ch.htmlとかが増えてるんだが
何があったんだw
603:デフォルトの名無しさん
09/08/01 19:31:20
そりゃあろいんの「2チャンミテマスヨ」という無形のプレッシャーに決まってるじゃん
whatchanged を見る限り、非 UTF-8 HTML を Nokogiri::HTML(html).to_html して
doc.encoding がうまくいくかどうかテストするために入れたっぽい（若干改変してるが）
ある程度複雑な Shift_JIS の HTML が必要だったのだろう
604:デフォルトの名無しさん
09/08/01 19:34:42
あ、このへんね
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(github.com)
605:デフォルトの名無しさん
09/08/01 19:44:27
ねー、自分では作（れ）る気しないけど、あったら便利だなというライブラリってなんかある？
606:デフォルトの名無しさん
09/08/01 20:15:43
>>605
blade
607:デフォルトの名無しさん
09/08/01 20:37:49
>>605
・Win32APIの使いやすいラッパー
・pure ruby版Nokogiri
・pure rubyかつ強力な画像処理ライブラリ
ライブラリじゃないけど番外で
・RDEのような軽量開発環境＋クロスプラットフォーム＋安定
・GUIビルダー
608:デフォルトの名無しさん
09/08/01 21:41:11
せいぜいサムネールが作れてあとは縦横のサイズが取れるくらいの
画像処理ライブラリは欲しいなー。
RMagickはかさばりすぐる。
609:デフォルトの名無しさん
09/08/01 22:24:17
pureRuby厨うぜえ
超遅い部分をCで書き直して何が悪いんだよ
610:デフォルトの名無しさん
09/08/01 22:36:24
pureRuby厨分類
* 原理主義 (とにかくPureRubyこそ至上、MRI以外で困るから)
* 標準添付はよい(rootのない環境で困るから)
611:デフォルトの名無しさん
09/08/01 22:41:56
>>609
過剰反応うぜえ
612:デフォルトの名無しさん
09/08/01 22:49:07
REXMLがPure Rubyであの重さなわけだが・・・
613:デフォルトの名無しさん
09/08/01 22:55:42
>>610
「CGIで動かないと困る派」も追加で
614:デフォルトの名無しさん
09/08/01 23:28:34
nokogiriは素晴らしい
615:デフォルトの名無しさん
09/08/01 23:29:28
自演乙
616:デフォルトの名無しさん
09/08/01 23:31:12
だーれーのー
だーれーのー自ー演ー
>>613
「CじゃなくPureRubyで作りましたライブラリ」の動作速度でCGIが動いたら果てしなく困ると思うんだけどね
インストールさえできれば運用はどうでもいいのかしら
617:デフォルトの名無しさん
09/08/01 23:35:54
オバマ
618:デフォルトの名無しさん
09/08/01 23:36:07
pure rubyでも拡張ライブラリでもいいじゃない、使い分ければ
619:デフォルトの名無しさん
09/08/01 23:44:31
拡張をCで書く理由の8割くらいは「CGIとかで動作させたとき遅くてやってられないから」だと思うんだが
620:デフォルトの名無しさん
09/08/01 23:46:37
>>616
用途によってはpure rubyの速度で十分だし
そもそもCGIでは、たいていの場合pure ruby以外に選択肢がない
俺の経験から言えば
複雑な画像処理やファイル圧縮は厳しいが、JSON/YAMLのパースや文字コード変換程度なら特に問題はないなー
HTML（XML）のパースあたりになってくると微妙
621:デフォルトの名無しさん
09/08/02 00:22:23
>>619
Cの拡張ライブラリを入れることができるような環境であれば、そもそもCGI使わなくね？
今ではmod_rubyとかFastCGIとか色々あるんだし
622:デフォルトの名無しさん
09/08/02 00:45:51
「今では」、mod_rubyはありえんだろ
623:デフォルトの名無しさん
09/08/02 02:34:54
CじゃなくてもJavaで書き換えても爆速になるんじゃね？
>>556さんどうなんよ？
624:デフォルトの名無しさん
09/08/02 05:34:44
>>621
そうだねCで拡張書けるだけのCの知識があればRubyなんて使う必要ないよね全部Cで書くよね
625:デフォルトの名無しさん
09/08/02 07:51:52
速度が必要なところはCで、それ以外はもっと高級な言語でってのは普通のことだろ