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で、それ以外はもっと高級な言語でってのは普通のことだろ
626:デフォルトの名無しさん
09/08/02 08:59:22
>>624-625がどこにどう反論してるのか理解できない
627:デフォルトの名無しさん
09/08/02 11:14:10
遅いメソッドをプロファイラで割り出して、拡張ライブラリとしてCで書き直すって
よくやるんだけど、思った程速くならないんだよなぁ。
やっぱ rb_funcall とかしまくるくらいなら意味ないのかな？
628:デフォルトの名無しさん
09/08/02 11:48:16
Purerubyが遅いというのは甘え。どうせクソ設計のせい。
（性能が）足りぬ足りぬは工夫が足りぬってな。
629:デフォルトの名無しさん
09/08/02 12:02:12
すごいな、全世界のRubyユーザーが揃ってクソ設計してるなんて
…それって言語側に原因があるんじゃね？
630:デフォルトの名無しさん
09/08/02 12:07:25
nokogiriとREXMLの圧倒的な差
631:デフォルトの名無しさん
09/08/02 12:07:45
>>628
さすがにC言語と比較してそれはない
632:デフォルトの名無しさん
09/08/02 12:14:16
>>605
win32用の高速なcrc16計算ライブラリが欲しい。今すぐに！
633:デフォルトの名無しさん
09/08/02 13:06:46
.NET FrameworkにCRC32すら入ってなくて絶望した俺が通り過ぎます
634:デフォルトの名無しさん
09/08/02 13:28:11
>>632
Cでいいか？
635:デフォルトの名無しさん
09/08/02 13:55:02
rubyも、pure ruby界とC界の境界面で高いコストが掛かる実装なの？
頻繁にCで書いたメソッド呼ぶとマーシャリングで余計遅くなるとか？
636:デフォルトの名無しさん
09/08/02 14:03:54
Windowsを使ってるやつにCRCなんぞ不要。ファイルが壊れてたら
再送すればいいだけ。
637:デフォルトの名無しさん
09/08/02 14:10:40
つかMD5やSHA-1じゃなくあえてCRCが要求される場面って何？
速度的にCRCが爆速ってわけでもないのに
638:デフォルトの名無しさん
09/08/02 14:11:17
>>637
既存のファイルフォーマットなりプロトコルがCRC32を使っている場合
639:デフォルトの名無しさん
09/08/02 14:18:11
歴史的経緯って奴だな
新規でCRC32を使用することはなかろう
640:デフォルトの名無しさん
09/08/02 16:09:29
CRC32だったらZlib.crc32が使えるね。
CRC16だと自分で用意しないとダメだなぁ。
641:デフォルトの名無しさん
09/08/02 18:30:01
>>262-263 あたりのnokogiriの話。
どうもnokogiriのWindows版gemに同梱されてるDLLは
libXML2の公式サイトからリンクされてる
URLﾘﾝｸ(www.zlatkovic.com)
のもののようなので、
URLﾘﾝｸ(www.zlatkovic.com)
のDLLの情報等を参考にしつつ、libiconvの1.13に
森山さんのところのパッチ
URLﾘﾝｸ(www2d.biglobe.ne.jp)
をあてたものを
MinGW/MSYSでビルドして、MSYS環境でそのままビルドすると
libiconv-2.dllとかしか出来ないので、ビルド時に生成された*.oに
libiconv-2.dllから抜き出したdefファイルを加えて
dllwrapでiconv.dllを生成……
ということで結果としてlibiconv-1.13-ja-1相当のiconv.dllを
作成してdllの検索パス(nokogiriの元の構成通りだとbin直下)に
配置したところ、>>262の
>#Shift_JISの範囲外の文字を含んだWindows-31J(=CP932)エンコーディングの文字列
>irb(main):001:0> s="<html><HEAD><TITLE>1１①1１①</TITLE></HEAD><body></body></html>"
>=> "<html><HEAD><TITLE>1１①1１①</TITLE></HEAD><body></body></html>"
>#Windows-31JエンコーディングでHTMLパース。失敗。
>irb(main):003:0> Nokogiri::HTML.parse(s,nil,'Windows-31J')
が通るように。
とりあえず今回生成したiconv.dllは
需要があるかどうか何とも言えないけどうpっておきます。
URLﾘﾝｸ(www1.axfc.net)
642:デフォルトの名無しさん
09/08/02 18:36:46
pureRubyじゃないときに困るのは一部のプラットフォームにしか対応してないとか
バイナリパッケージがない場合とかですかね。
もはやmswin32(というかActiveScriptRubyとOne-Click Installer)が
Rubyユーザの最大勢力なわけで、大抵そのあたりでもめるというか。
643:デフォルトの名無しさん
09/08/02 19:50:03
最大勢力の欲求が常に正しいとは限らないし、満たしてやる必要もない
644:デフォルトの名無しさん
09/08/02 20:00:54
と、思いつつ最終的に「満たすことになる」のが世の習いでもあり。
実際（別視点で見たときの）最大勢力であるRails勢の望みは
リリースエンジニアリング含めかなり呑むことになったわけで。
もちろん言語仕様的な部分とかでまつもとさんが一線を守るのは
悪くないけれども、じゃあこの点については実際のところどうなの、
という話になるわけで。
645:デフォルトの名無しさん
09/08/02 20:10:58
>>643
The Netが商用利用に解放された当時、そのころの細い回線を大事に
使っていた人たちのうちくちさがない人々は
「一般人にネットなど与えるな」などと言ったものでした
当時の旗振り役が答えて曰く
「そうなればいずれ彼らは自分たちでネットを生み出し今のネットにとって変わるだろう」
「もしそうであればそのとき君たちの居場所はあるだろうか?」
と
まあ実際その通りになったのですが
646:デフォルトの名無しさん
09/08/02 20:34:41
へー
自分たちでネットを生み出したんだ。そんな歴史初耳w
647:デフォルトの名無しさん
09/08/02 20:44:12
>>初心者スレの821
rb_block_tのproc見て、なかったらiseq->argc見れば変換はいらなくね？
とはいえそんなのはキモすぎて御免だが
648:デフォルトの名無しさん
09/08/02 21:33:52
>>646
無知ですねえ。
これだから自称古参は困るw
649:デフォルトの名無しさん
09/08/02 21:35:58
じいさんの昔話はレトロ板でやってくれ
650:デフォルトの名無しさん
09/08/02 23:55:32
>>632
>>640
URLﾘﾝｸ(www.zorc.breitbandkatze.de) ( URLﾘﾝｸ(www.zorc.breitbandkatze.de) )
URLﾘﾝｸ(boost.cppll.jp)
651:デフォルトの名無しさん
09/08/03 10:41:21
年寄りは今の時代についていけないからな。昔話するしか無い。
戦争は悲惨だから嫌だとか逝って競争することを放棄した年寄りが日本を駄目にした。気がつけば競争力無くて景気低迷。ちゃっかり競争が無いはずの非資本主義の支那に美味しい所を持っていかれてる。
ピュアルビーが遅いのって、ルビーインタラプタが遅いからだろ。
信者は、教祖の実装がゴミのせいで遅いと口が避けても言えないってだけじゃ。
652:デフォルトの名無しさん
09/08/03 10:45:38
URLﾘﾝｸ(jp.rubyist.net)
みれない
653:デフォルトの名無しさん
09/08/03 10:57:44
>>651
URLﾘﾝｸ(hideyoshi.2ch.net)
654:デフォルトの名無しさん
09/08/03 11:43:28
インタラプタについて語るスレになりまつた。
655:デフォルトの名無しさん
09/08/03 11:57:12
1.8のコードなんてもう読んでないからインタラプタとかよくわかんあい
656:デフォルトの名無しさん
09/08/03 12:25:25
>>651
さっさと核戦争やれ
まで読んだ
657:デフォルトの名無しさん
09/08/03 12:47:33
ルビーインドヒマラヤ
658:デフォルトの名無しさん
09/08/03 13:15:34
>>651
その種の文句は方々で言われてるだろ。
matzはコミット権を取り上げると脅される程度の扱いだぞ。
659:デフォルトの名無しさん
09/08/03 13:24:37
>>658
あんまりネタを引っ張ってると恥ずかしいよ
あれはあくまでテストとドキュメント書けって話だし
660:デフォルトの名無しさん
09/08/03 14:04:53
でもまあ「コードがドキュメントだ」的な発言は粉砕されてしまうようになったかな
661:デフォルトの名無しさん
09/08/03 14:11:11
実際にマニュアル文書こうとするとわかるが、Ruby スクリプト部分に関してはコード読ませたほうが早い
それこそ「変数 i に整数 10 を代入する」レベルのことにしかならなかったり
必要なのは、個々のメソッド動作の詳説ではなく、網羅的なメソッド動作一覧だったりする
662:デフォルトの名無しさん
09/08/03 15:16:33
スクリプトの説明とマニュアルは違う
コードの動作を知らせるのならそりゃコード読ませたほうが早いが
コードの動作が何を意図しているのかを明確にするために
ドキュメントを書くべき
663:デフォルトの名無しさん
09/08/03 15:18:15
ドキュメントとマニュアルは開発者が書かなくてもよい
別の人が書いてもよい
664:デフォルトの名無しさん
09/08/03 15:32:53
ドキュメントやマニュアルとはそもそもなんぞやという話に
665:デフォルトの名無しさん
09/08/03 18:52:42
ドキュメントはChangeLogとかも含むかな
666:デフォルトの名無しさん
09/08/04 00:06:50
作った香具師しか分からない様な糞コードだからドキュメントが必要。
cgi.rbなんて典型だろ。
667:デフォルトの名無しさん
09/08/04 00:09:35
きちんとしたドキュメントがあるのとないのとで、使い方から潜在的なバグの発見まで
どれだけ敷居が低くなるのかってことはあるはずなんだが。
そもそも人に使って貰うことを前提に公開・配布してるんと違うんかと。
668:デフォルトの名無しさん
09/08/04 00:55:56
cgi.rbが糞コードってのは公認なの？
俺がアホだから解りづらいのか、糞コードだから解りづらいのか、
どっちなのか悩んだ事があったんだが。
669:デフォルトの名無しさん
09/08/04 01:11:55
PerlのCGIモジュールの再実装だから、当然・・・。
670:デフォルトの名無しさん
09/08/04 01:58:15
あれは「これをもとにブラッシュアップする」という予定をすっ飛ばされたライブラリだから
cgi.rb 自体が悪いというよりは、それこそリリースエンジニアリングが悪い
671:デフォルトの名無しさん
09/08/04 02:15:08
そもそも「CGI汎用対応ライブラリ」は実装が汚くなる傾向にある
バージョン 0.2 くらいでは非常に理想的なコード進行なんだが、
バージョン 0.95 になると特殊条件割り込みやら外部バグ対応やらでぐちゃぐちゃに
672:デフォルトの名無しさん
09/08/04 02:37:35
ライブラリの中がある程度汚くなるのは仕方ない分野もあるってことかな
その分、APIの統一やらドキュメントの充実やらで対応するのが常道だろうけど
ソース嫁って意見はその辺はどう考えてるんだろうか
まさかコメントあるからおｋってことでも無かろうが
673:デフォルトの名無しさん
09/08/04 04:36:26
できれば標準ライブラリは一番綺麗なお手本でいてほしい。
その言語処理系でなにかしようとするなら、まず標準ライブラリを参考にするし。
ただ、「これをもとにブラッシュアップ」とか言ってたらオープンソースじゃ
一生リリースできないからね。何もないよりは、はやリリしょちゅリリのほうがいいよ。
ここでグダグダ言ってるよりか何か書いてパッチでも送りつけるorパッチ袋に
蓄積するというほうが現実的なんではないかな。あ、俺はやらないけどw
そんな暇あったら自分の仕事するしw
674:デフォルトの名無しさん
09/08/04 06:07:19
ちなみに、cgi.rbをブラッシュアップするぜと言ってメンテナになられた奇特な方がxibbarさんなので、
みなさん意見とか言ってあげてください
675:デフォルトの名無しさん
09/08/04 06:30:59
え、何が楽しいのとか馬鹿じゃねーのとか他のことやったらとかそういう意見でもいい？
676:デフォルトの名無しさん
09/08/04 06:35:53
WEBrickにセッション機能つけてcgi.rb捨てようぜ
677:デフォルトの名無しさん
09/08/04 08:23:39
むしろRackを標準にしてcgi.rbを捨てるのがいいんじゃね
あと、確か一時期cgialtに置き換えようって動きもあったよね
あれどうなったのかな
678:デフォルトの名無しさん
09/08/04 08:26:23
Rack は CGI 環境での動作テストをせずにガンガンリリースしまくったという負の実績が…
679:デフォルトの名無しさん
09/08/04 08:28:24
>>651
ｽﾚﾘﾝｸ(newsplus板)
680:デフォルトの名無しさん
09/08/04 08:48:59
>>678
それで1.0.0でもCGIが動かないという恐るべき状況になったのか
681:デフォルトの名無しさん
09/08/04 10:07:18
>>677
Ruby本体では、年1リリースでも支障がない程度に安定していることという暗黙の前提があるので、
Rackが入るにはもうしばらくかかるんじゃないかな。
たまに話が出るFFIも同様の理由で当分はない。
CGIAltにはすでに置き換わってるよ。
気づかなかったとしたらそれはxibbarさんが慎重にテストしながら置き換えた成果だね。
682:デフォルトの名無しさん
09/08/04 10:13:58
>>675
> え、何が楽しいのとか馬鹿じゃねーのとか他のことやったらとかそういう意見でもいい？
同旨の事は言った気がする（ぉ
683:デフォルトの名無しさん
09/08/04 10:29:43
ライブラリのソースを読んだ知見を元に何でドキュメントを書かないの？
684:デフォルトの名無しさん
09/08/04 10:39:36
ソースを読む才能とドキュメントを書く才能って別なんだよね。
リファレンスマニュアルならすでにあるし
685:デフォルトの名無しさん
09/08/04 10:43:36
それが理解できず開発者にドキュメントを強いる衆愚
686:デフォルトの名無しさん
09/08/04 11:16:57
引き篭もりはこれだから困る（）笑
現実の世界見てみろよ！
製作者が公演したり解説したり本書いたりするのが当たり前だから！
そして微妙な空気に支配される会場！がっかりが埋め尽くす書評！
無下にするわけにもハブるわけにもいかず仕方なく「スーパーバイザー」とかよくわからん横文字で濁されるお茶！
687:デフォルトの名無しさん
09/08/04 11:21:03
ああ、監修：ま何某ってそういう…
688:デフォルトの名無しさん
09/08/04 11:21:50
>>686
無知、乙
689:デフォルトの名無しさん
09/08/04 11:30:20
そういう役割分担というか、専門技能へのドライな眼差しは、
日本人が苦手としているところかもね。
スポーツでも、日本文化に古くから染み込みすぎて旧態依然としている分野（野球、相撲）ほど、
プレーヤーとトレーナー&マネージャーをごっちゃにするし。
690:デフォルトの名無しさん
09/08/04 11:30:34
>>686
関係者かなんか知らんけどあんな人無理に壇上で喋らせなくてもいいのに、と思うことはなくもない
せめて巷の体育の先生くらいには話のできる人がフォローすべき
インタビュー形式とか色々あんじゃんね
Ruby関係ないな
691:デフォルトの名無しさん
09/08/04 11:48:36
いや、あの公演、当日までスライドできて無くてアレしゃべってるんだぜ
すごい才能だと思わないか
いや、別にほめられた事じゃないけどさ
692:デフォルトの名無しさん
09/08/04 12:35:54
もちおみたいにオープンソースの理解も足りないんだろうな
あと、多くは開発者以外がドキュメントを書いている事実も。
Ruby 以外の言語も知っておくのは、そういう意味でも重要。
693:デフォルトの名無しさん
09/08/04 12:37:19
>>688=>>692
694:デフォルトの名無しさん
09/08/04 13:55:42
>>681
>CGIAltにはすでに置き換わってるよ。
ダウト
695:sage
09/08/04 15:11:48
>694
1.8系しか見てないのかな
696:デフォルトの名無しさん
09/08/04 15:17:46
>>694
おおう、たしかにCGIAltそのものではなかった
URLﾘﾝｸ(d.hatena.ne.jp)
697:デフォルトの名無しさん
09/08/06 22:06:18
IronRuby 0.9
698:デフォルトの名無しさん
09/08/06 23:01:11
IronRubyとJRuby、なぜ差がついたか… 資金、開発環境の違い・・・
699:デフォルトの名無しさん
09/08/06 23:24:23
>>698
どっちがいいの？
700:デフォルトの名無しさん
09/08/06 23:39:00
どっちも駄目
まだ
きちんと一定の形に完成しないのなら意味がない
701:デフォルトの名無しさん
09/08/06 23:41:59
JRubyは完成したとして何に使うのかがよくわからない
IronRubyはWin環境でのライブラリ不足を一挙に解決してくれるからな
702:デフォルトの名無しさん
09/08/07 00:01:12
ふと一行78文字ルールと戦うIronPythonデベロッパの姿が脳裏に浮かんだ
703:デフォルトの名無しさん
09/08/07 00:26:51
JRubyだってJavaのライブラリ使えるのが強みだろうさ
あとJVMが動く場所なら動くことと、JVMが速くなりゃJRubyも速くなること
704:デフォルトの名無しさん
09/08/07 04:03:18
1.9.1の最新版のmswin32のバイナリは出ないのだろうか・・・
705:デフォルトの名無しさん
09/08/07 08:33:10
>>700
「きちんと一定の形」についてもう少しkwsk
706:デフォルトの名無しさん
09/08/07 08:47:11
>>704
fURLﾘﾝｸ(ftp.ruby-lang.org)
URLﾘﾝｸ(blade.nagaokaut.ac.jp)
なぜusaさんのページで出てないのかは謎
707:デフォルトの名無しさん
09/08/07 11:50:58
jrubyはもう駄目だろ Sunにさえ見放された
IronRubyは世界標準のWindowsだし、世界最強IT会社のMS製だし・・・
708:デフォルトの名無しさん
09/08/07 12:07:19
マイクロソフトが手を出せば成功するというのなら世の中はとっくに
709:デフォルトの名無しさん
09/08/07 12:26:30
Ruby の今後について、マーケティング用語「キャズム」を紹介する
URLﾘﾝｸ(www.mitsue.co.jp)
一般的にテクノロジーのライフサイクルはベル型の標準偏差のグラフによって示され、
その各段階でターゲットとすべき顧客として、イノベーター、アーリー・アドプ
ター、アーリー・マジョリティ、レイト・マジョリティ、ラガードといった顧客セグ
メントが行なわれます。通常、この顧客セグメントによって、異なるマーケティング
施策を行いながら、徐々に新しいテクノロジーの顧客層を広げていくことが推奨され
ます。しかし、米のマーケティング・コンサルタントであるジェフリー・ムーア氏が、
同名の著書によって、明らかにしたのは、イノベーターとアーリー・アドプター
で構成される初期市場と、アーリー・マジョリティやレイト・マジョリティによって
構成されるメジャー市場のあいだには、容易には越えがたい「キャズム（深いミ
ゾ）」あるということでした。顧客セグメントの違いによって生み出される、この
キャズムを超えなくては、新しい商品はメジャー市場でブレイクすることなく、規模
の小さな初期市場のなかでやがては消えていく運命となります。同著が、10年間にわ
たって米国ハイテク業界のバイブルとされたように、特にテクノロジーの進歩の激し
い業界においては、強く意識することが重要なマーケティング理論です。
以下は、マーケティングの視点で、Twitter の普及を分析
Twitter の快進撃がとまった!?～スローダウンの要因を分析する
URLﾘﾝｸ(japan.internet.com)
710:デフォルトの名無しさん
09/08/07 12:35:14
ふだんは Java と Ruby を両方いじっている者だが
(Java 系のエンジニアだが、さいきん Rails も覚えた)
Java のプロジェクト内ライブラリを叩く運用ツール(半使い捨て)を、
# たとえば 在庫一覧をファイルに出力するツールなど
いまは Java のプログラムでつくっているが、
これを JRuby でやるようにしたら、もっと手軽に作れないかなと思っている。
JRuby は、マルチスレッドプログラミングするなら Ruby 1.9 系よりも速いんじゃなかったっけ？
このスレだかどこかで読んだような
711:デフォルトの名無しさん
09/08/07 12:51:12
>710
そういうのは、Scalaでやった方がいいと思う。
712:デフォルトの名無しさん
09/08/07 13:12:29
>>710
Javaなら一応Groovyとかもあるかな
arton氏が似たようなシチュエーションでrake使って
自動化とか効率化とかやってたはず
713:710
09/08/07 13:17:10
>>712
Groovy は少しかじったけど、なんかいまいち。
Ruby のほうが見やすいし、Ruby / Groovy でできないところは Java で書く。
Groovy は Java しか出来ない人のスクリプト言語って感じだけど、Ruby 本物を覚えてしまった今、
いまいち中途半端だなあと感じる。
>>711
Scala でも使い捨てスクリプトをちゃちゃっと作れるのかな。
714:デフォルトの名無しさん
09/08/07 14:24:50
JRubyがもう少し起動早くなったらGUIが気持ちよくかけるかもしれない
715:デフォルトの名無しさん
09/08/07 17:19:04
>>713
そんなことない。
Groovyは最初からJavaと連携できるよう考慮されているから、Javaもよく使うならJRubyよりGroovyのほうがいい。
JRubyはあくまでRubyをJVMで使いたい人向け。
716:710
09/08/07 17:38:54
>>715
なるほど。
どうやら自分は、まだ Groovy への理解が足りないようだ。もうちょっと勉強してみるよ。
でも、るび厨になってしまったので、Ruby や JRuby いじっているほうが楽しいんだけどね。
717:デフォルトの名無しさん
09/08/07 21:53:14
あとGroovyは一時はJavaSDKに標準添付の話まであったのに
そのあと大きな動きがなくてプロジェクトが死んじゃってるんじゃねえの、って状態なのも難点かなあ
718:デフォルトの名無しさん
09/08/07 22:22:20
Groovyはコレの24p以降のイメージが強烈すぎた
URLﾘﾝｸ(kakutani.com)
719:デフォルトの名無しさん
09/08/07 23:21:26
おまえらのせいでGroovyに興味が湧いてきた
720:デフォルトの名無しさん
09/08/07 23:43:45
>718
なんだこれｗｗｗｗｗｗｗ
721:デフォルトの名無しさん
09/08/07 23:49:51
なついなあライブでみたよ
722:デフォルトの名無しさん
09/08/07 23:53:53
>>718
無駄に力作過ぎるが、全体を通してみてこれで使ってみたくなるか？という素朴な疑問
公平な紹介ってなんだろうけど
723:デフォルトの名無しさん
09/08/08 09:25:45
>>718
ネタ帳かとおもたwwwwwwww
724:デフォルトの名無しさん
09/08/08 09:28:03
弱点
● 機能セットがすべて出揃っていない
? 匿名インナークラスが未サポート（Groovy-1.1までに対応?)
? モダンなIDEでのサポートが不十分(Eclipse, IntelliJ...)
● 実行速度が遅い
? 対Java比: 20～90%
● デバッギング・ヘル!
? パーサが未成熟: わけのわからんエラーメッセージ
wwwwww
725:デフォルトの名無しさん
09/08/08 10:20:13
>>724
それ、いつのこと？現時点での話じゃないよね
726:デフォルトの名無しさん
09/08/08 11:37:41
>>725
>>718のPDFを見れば書いてあるよな
727:デフォルトの名無しさん
09/08/08 11:53:34
Ruby 初心者スレッド Part 30
ｽﾚﾘﾝｸ(tech板)
初心者スレが立ちました
アンチスレは落ちたままです
最終の遣り取りは以下の通り
> 979 名前：デフォルトの名無しさん [sage] 投稿日：2009/08/06(木) 19:50:29
> Ruby ってメモリ馬鹿食いするよね？
>
> 980 名前：デフォルトの名無しさん [sage] 投稿日：2009/08/06(木) 19:57:59
> まあ、そこそこには
> 省メモリで動作することが重要なのならRubyは使ってはいけない
728:デフォルトの名無しさん
09/08/08 12:41:08
>>726
>>>718のPDFを見れば書いてあるよな
それ、2004年の資料だよね。だから>>724は現時点での話じゃないよね。
おわかり？
729:デフォルトの名無しさん
09/08/08 12:51:02
別にいいけどおまえの言うことを
必死でくみ取ってくれる存在なんて両親くらいだぞ
730:デフォルトの名無しさん
09/08/08 13:14:14
Rubyの会のサイトって死んでるの？
解散した訳じゃないよね？
URLﾘﾝｸ(jp.rubyist.net)
731:デフォルトの名無しさん
09/08/08 13:35:53
>730
最近サーバの調子が悪いらしい
732:デフォルトの名無しさん
09/08/08 13:39:03
PJの社長みたいに金余ってる人がスポンサーにつかないものか
733:デフォルトの名無しさん
09/08/08 13:50:15
最近と言っても、ここ数日の話なので仕方ないと思われる。
734:デフォルトの名無しさん
09/08/08 17:07:25
1.8の方のDLってひょっとして可変長引数扱えないのかな。
ruby-ffiは出来るみたいだからそっちでごまかすかのう。
735:デフォルトの名無しさん
09/08/08 20:02:51
>>732
Ruby 界隈でイケメンはいないだろ
736:デフォルトの名無しさん
09/08/08 20:44:54
アンチスレも消えてすっきりしたな
737:デフォルトの名無しさん
09/08/08 23:09:44
>735
_why はイケメン。
738:デフォルトの名無しさん
09/08/08 23:50:23
これって既出ですかね？
Ruby1.9.1、Python3.1、Java1.6.0の実行速度比較
URLﾘﾝｸ(www.mwsoft.jp)
1.8は遅かったけど1.9はかなり速くなったと聞いてたので
そろそろRubyをしっかり勉強するのもありかなと思ってたんですが
この結果を見て愕然としました
何故にこれほど遅いんでしょう…
もう高速化の手段は残ってないんでしょうか…
739:デフォルトの名無しさん
09/08/08 23:59:25
WindowsでRubyって・・・
740:デフォルトの名無しさん
09/08/09 00:17:54
>>738
高速化技法はまだ全然試されていないからまだまだ伸び代はある。
Pythonも高速化計画が持ち上がってたはずだし。
741:デフォルトの名無しさん
09/08/09 00:18:17
そういえばRubyが遅い遅いとは言われてるけど
なんで（少なくともベンチマーク上では）遅いのか、その理由がよくわからない
1.9.1からYARVが入って、他の言語と同じバイトコンパイルになったはずだし
Pythonあたりと柔軟性で極端な違いがあるとも思えないし
742:デフォルトの名無しさん
09/08/09 00:19:57
>>738
きっきっと、新しいバージョンだから遅いいんだよ
最適化された・・・バージョンアナら・・・ぼぼろ負けはしないよ
>>739
LinuxにはPython入ってるから、Windowsで・・・
743:デフォルトの名無しさん
09/08/09 00:27:05
正直、じゃんごの日本語リファレンスとかもうちょっと充実してきたら
Pythonに移ってもいいかなって思ってる
744:デフォルトの名無しさん
09/08/09 00:31:09
俺は日本語リファレンスが充実しても、Pythonには行かないなー
Rubyが使いやすすぎて、ちょっとやそっとの速度差で止める気にはならない
どうしても速度が気になるなら拡張ライブラリがあるし
745:デフォルトの名無しさん
09/08/09 00:35:37
IronRubyによってMSが10倍速にしてくれるから気にするな
Linuxは知らん
746:デフォルトの名無しさん
09/08/09 00:36:34
>>745
その時には素敵な拡張文法がてんこ盛りだったりして
747:デフォルトの名無しさん
09/08/09 01:20:32
JRubyでいいじゃんはやいじゃん
748:デフォルトの名無しさん
09/08/09 01:46:45
とりあえずRubyがWindows上で遅い、特に一定の条件が揃うと妙に遅いというのは前から言われてる
あと、usa版バイナリはVC6でコンパイルしているので最適化が甘い
ので、まずはコンパイラを揃えてテストするべき
749:デフォルトの名無しさん
09/08/09 01:48:48
ということは、mingw版の方が速い可能性があるってことなのか
750:デフォルトの名無しさん
09/08/09 01:52:45
というか、Linuxサーバー上で運用されることが実際には多いんだから
Linuxでテストしないと意味がないと思うんだが・・・
Windowsサーバー使えるような企業やハイソサエティはRubyなんて使わんで
ASP.NET使うだろｊｋ・・・
751:デフォルトの名無しさん
09/08/09 07:46:33
> ということは、mingw版の方が速い可能性があるってことなのか
まぁ、それはあるけど、素直にVC9を使うのが楽だと思うよ
> Windowsサーバー使えるような企業やハイソサエティはRubyなんて使わんで
> ASP.NET使うだろｊｋ・・・
IronRubyをテストしてあげて！
752:デフォルトの名無しさん
09/08/09 09:02:21
>>751
またそんないばらの道を...
というかmingw32のほうがVC(9含めて)よりはやいというのは、以前からわかってる。
753:デフォルトの名無しさん
09/08/09 16:41:58
Windowsならgcc -O3で野良だろJK
754:デフォルトの名無しさん
09/08/09 16:46:52
Ruby/Tkさえコンパイルできるようになれば、すぐにmingw版に移るんだが
755:デフォルトの名無しさん
09/08/09 17:00:11
>>754
普通にできてるが
756:754
09/08/09 17:12:14
>>755
え、本当？
俺の環境では ruby-list:46093 と同じ問題でコンパイルできない・・・
何が問題なのかさっぱりだ
配布バイナリがあればそっちを使うんだけど、更新止まってるみたいだし
757:デフォルトの名無しさん
09/08/09 17:31:30
>>753
GCの関係で、最適化かけすぎると
不味いんじゃなかったっけ？
758:デフォルトの名無しさん
09/08/09 17:52:37
ソースコード完全解説には「-O2まで」と載ってるな
URLﾘﾝｸ(i.loveruby.net) （「最適化のヒント」の項）
759:デフォルトの名無しさん
09/08/09 18:45:58
>>758
むしろ-O3より-O2の方がコンパイルに時間がかかったって話も聞くけどな
760:デフォルトの名無しさん
09/08/09 19:01:57
The Computer Language Benchmarks Game
URLﾘﾝｸ(shootout.alioth.debian.org)
761:デフォルトの名無しさん
09/08/09 19:57:53
>>758
いつの時代の本だよ
762:デフォルトの名無しさん
09/08/09 21:22:36
いやgccの-O2と-O3の差とか、当時とそんなに変わってないし、
Rubyもevalこそ入れ替わったけど、GCは基本同じだし。
763:デフォルトの名無しさん
09/08/09 22:10:26
RHG1.9版出せよ
764:デフォルトの名無しさん
09/08/09 22:18:27
OneClickRubyInstaller の次期バージョンになる予定のRubyInstallerは、
mingw版です。ダウンロードできるけど、まだプレビュー版です。
URLﾘﾝｸ(rubyinstaller.org)
みんなでテストして、安定すれば問題解決じゃない？
1.8系はmingwにするだけで倍以上早くなるみたいだし。
URLﾘﾝｸ(antoniocangiano.com)
765:755
09/08/10 00:15:17
>>756
俺もstubはダメだったんで非stubで使ってる。
Tcl/Tk 8.5 以降できなくなったような気がする。
ちなみにActiveTcljは使ったこと無い。いつもソースからビルドしてる。
766:デフォルトの名無しさん
09/08/10 03:28:30
>>762
> いやgccの-O2と-O3の差とか、当時とそんなに変わってないし、
ソースだせソース
767:デフォルトの名無しさん
09/08/10 07:13:49
最近は-O3でも動くらしい（ソースはIRCでの中田さんの発言
768:デフォルトの名無しさん
09/08/10 08:37:56
もう1年以上-O3のRuby(MinGWとlinux)使ってるけど
特に問題になったことはないなあ
769:デフォルトの名無しさん
09/08/10 20:17:04
少なくとも写真はこっちが勝ちだな
「変わっていかなければ」。日本Rubyの会 会長の葛藤 － ＠IT自分戦略研究所
URLﾘﾝｸ(jibun.atmarkit.co.jp)
770:デフォルトの名無しさん
09/08/10 20:23:33
世界にはばたく日本のRuby（笑）から（笑）を取ってもいい頃合の状況なのに、
実際の中の人の活動は状況に比べて芳しくないんだよね
771:デフォルトの名無しさん
09/08/10 20:50:57
Javaの解説やドキュメントを書くのは楽しい
なぜなら、足りない部分を補填するという自覚がもてるからだ
Rubyの解説やドキュメントを書くのは楽しくない
なぜなら、余計なものを重複して書いてる気分になるからだ
Rubyのスクリプトコードがもうちょっと読みにくかったら
ドキュメンテーションへのインセンティブになると思う
772:デフォルトの名無しさん
09/08/10 23:57:13
> Javaの解説やドキュメントを書くのは楽しい
奇特な性癖の持ち主発見
773:デフォルトの名無しさん
09/08/11 01:02:30
内容から察するに、わざわざツッコミ入れなくてもそういう意味だと思うぞ
「Rubyに比べてJavaのコードは解りにくいから、むしろドキュメント書くのが楽しくなる」という内容のようだから
774:デフォルトの名無しさん
09/08/11 01:22:03
実際にはJavaでもろくに書いてないんだろうけどな
775:デフォルトの名無しさん
09/08/11 01:25:32
分かりきったことをあらためて書くことほどつまらないことはないので
気持ちはわからなくもない
776:デフォルトの名無しさん
09/08/11 01:29:55
成程>>769での懸念も尤もだな
よっぽどJavaの4文字に負い目があるらしい
777:デフォルトの名無しさん
09/08/11 08:39:14
メッセージ伝達手段としての例外って使わないほうがいい？
1.9ではそもそも遅いとか聞くし
778:デフォルトの名無しさん
09/08/11 09:43:54
>>777
例外は例外なんだから例外的なことが起きた時にだけ使うべきだろう。
779:デフォルトの名無しさん
09/08/11 10:00:13
>>778
正論
大域脱出だったら catch と throw でいいんじゃないの？
780:デフォルトの名無しさん
09/08/11 11:10:02
Rubyでのthrow-catchはbegin-raiseとどう使い分けるの？
ふつうに例外処理があるのになんでcatch-throwがあるの？
初心者の素朴な疑問。
781:デフォルトの名無しさん
09/08/11 11:22:56
>>780
779が書いたように、throw～catchは大域脱出機構。
例外処理機構じゃない。
782:デフォルトの名無しさん
09/08/11 11:36:29
>>777
基本的には使うべきでない
ただしメッセージの種類によっては、判定が微妙なこともある
例：net/http.rb や open-uri.rb のHTTP例外
783:デフォルトの名無しさん
09/08/11 11:41:53
elseでのreturnは例外送出と根源的には同質
キャッチするかそのままにするかの違いでしかない
784:デフォルトの名無しさん
09/08/11 12:31:49
>>779
ライブラリが「このメソッドを呼ぶ時はcatchで括ってください」とか言ってきたらイヤだぞｗ
785:デフォルトの名無しさん
09/08/11 12:38:26
PStore#transactionとか
786:デフォルトの名無しさん
09/08/11 12:50:53
>>785
コード見て理解できた、指摘thx
787:デフォルトの名無しさん
09/08/11 15:05:47
>>785
理解できないので解説おねがい
788:デフォルトの名無しさん
09/08/11 15:07:48
>>784
検索メソッドを中断したらabort投げられるなんてのもないでもない
789:デフォルトの名無しさん
09/08/11 15:08:03
PStoreというクラスのインスタンスメソッドtransactionという意味
790:デフォルトの名無しさん
09/08/11 15:32:35
python の __getattr__ (属性へのアクセスのフック)のような事を ruby で行いたいのだがどうやれば良い？
method_missing ならぬ attr_missing みたいなメソッドがあれば良いんだけど発見できなかった。
791:デフォルトの名無しさん
09/08/11 15:49:05
できません
「インスタンス変数へのアクセスは全員アクセサメソッド使え」
とマニュアルにでっかい字で書いておくというのはどう
792:デフォルトの名無しさん
09/08/11 16:31:01
>>791
ｔｈｘ。
俺が見つけられなかっただけで、rubyでも絶対出来る方法があるだろーと思っていただけに意外でした。
793:デフォルトの名無しさん
09/08/11 18:24:41
>>789
だれもそんなこときいてねー！！
例外やcatch-throwの話しているときになぜ
>PStore#transactionとか
がでてきたのか（たとえばPStore#transactionがcatch-throwを使ってるとか）を聞いてるんだけど。
これが空気読めない理系どものコミュニケーション能力か！
794:デフォルトの名無しさん
09/08/11 18:32:49
>>793
そういう君こそ >>789 が言外に込めた意味を汲み取るべきでは？
ちなみに件のコードは見た？
795:デフォルトの名無しさん
09/08/11 19:35:00
＞（たとえばPStore#transactionがcatch-throwを使ってるとか）を聞いてるんだけど
見てたらこんなこと言わないか、一年ROMれのレベル
796:デフォルトの名無しさん
09/08/11 20:26:54
そうか、コールバック（イベント）メソッドという手もあったな
797:デフォルトの名無しさん
09/08/11 23:46:42
RubyやPythonの例外の使われ方を考えると
例外を例外的な状況だけで使えというのは
Java独自の風習じゃないかと思えてくる。
798:デフォルトの名無しさん
09/08/11 23:51:55
ジャヴァの例外周りの仕様は明らかにウンコ
C++の<< >>なIO stream並にフォロワーが出てこない
799:デフォルトの名無しさん
09/08/12 00:24:07
C++の例外はうんこ以前に普通に使えないという代物だからなあ
うんこはまだ食べられるだけマシだろ
800:デフォルトの名無しさん
09/08/12 04:42:59
それは例外ではなくただのエラーだと突っ込みたくなることが何度か
801:デフォルトの名無しさん
09/08/12 07:07:10
例外という日本語に引っ張られてるっぽい人は時々見る
802:デフォルトの名無しさん
09/08/12 07:20:25
>>792
trace的なものはあった気がするがすさまじく遅いから常用不可だった記憶
803:デフォルトの名無しさん
09/08/12 09:30:11
>>801
exception だとニュアンスがちがうのか？
804:デフォルトの名無しさん
09/08/12 09:38:30
「予期しないこと」ぐらいのニュアンスかな
805:デフォルトの名無しさん
09/08/12 09:41:00
よく知らんのだが、Lispのコンディションはもうちょっと積極的に
制御に組み込まれるんだろうか
806:デフォルトの名無しさん
09/08/12 09:45:43
>>801
例外なんて相対的なものだからね
ある人の例外は別の人にとって例外でなかったりする
807:デフォルトの名無しさん
09/08/12 09:58:03
OCamlの例外は積極的に制御機構として使われているね。
ループをbreakするときも例外とか。
よく知らんけど。
808:デフォルトの名無しさん
09/08/12 10:17:12
そもそもRubyの例外クラスには
StandardErrorなんてのが普通にあるんだし
それを考えても、エラーと例外をはっきり分ける意味はないと思う
809:デフォルトの名無しさん
09/08/12 10:36:09
例外って、実行時エラーに捕捉機能が備わっただけのような気もするな。
810:デフォルトの名無しさん
09/08/12 11:03:01
丸投げ機構
811:デフォルトの名無しさん
09/08/12 11:38:01
本スレに関係ない話題の隔離機構
812:デフォルトの名無しさん
09/08/12 13:01:02
むしろ本スレが隔離機構
813:デフォルトの名無しさん
09/08/12 13:13:33
隔離機構と薄力粉って似てるよね
814:デフォルトの名無しさん
09/08/12 13:20:53
隔離機構とカクリコンって似てるよね
815:デフォルトの名無しさん
09/08/12 13:24:16
∴ 薄力粉とカクリコンって似てるよね
816:デフォルトの名無しさん
09/08/12 13:39:36
>>790
method_missing 使え
Rubyはメソッドとか属性とかプロパティとか区別しない。
817:デフォルトの名無しさん
09/08/12 13:45:07
>>816
てゆか「メソッドしかない」んだけどね、厳密には
818:デフォルトの名無しさん
09/08/12 15:16:10
なんでこういう布教スレばっかり立てるん？
魁け！ Ruby 1.9.X
ｽﾚﾘﾝｸ(tech板)
819:デフォルトの名無しさん
09/08/12 16:17:53
>>818
何で今さら？
かなり前からあるぞそのスレw
820:デフォルトの名無しさん
09/08/12 21:09:26
MLの中にたこ焼き仮面がどうやらっていうメールがあって
何事かと思ったw
821:デフォルトの名無しさん
09/08/12 21:36:06
>>820
何で今さら？
かなり前からあれだぞそのカレw
822:デフォルトの名無しさん
09/08/12 21:56:32
>>821
そうだったのかw
ほとんどタイトルしか見ないからな
823:デフォルトの名無しさん
09/08/13 09:55:38
WEBrickのパースユーティリティって特定条件のパース遣り残しとか残ってる？
信用して丸投げしていい？
824:デフォルトの名無しさん
09/08/13 11:35:32
全く同じようなメソッドが大量に再発明されて氾濫してる現状からお察しください
825:デフォルトの名無しさん
09/08/13 11:51:36
やっぱり HTML とか HTTP とかの軽量クラスは作るべきだっただろうか
require 'cgi' が重いから嫌われてるんだよね escapeHTML
826:デフォルトの名無しさん
09/08/13 11:58:06
>>823
1.9でマルチバイト通さなかったことを誰も気づかなかった時点でお葬式
827:デフォルトの名無しさん
09/08/13 12:06:59
あのへんは、コードを読み解こうとしてRFCとか参照しようとするとわかるが、そもそも頭に入らないぞ
仕様読んでる時点で脳内スタックが溢れるという体験を久しぶりにした
「…このままでいいや」と呟いた俺
828:デフォルトの名無しさん
09/08/13 12:14:41
Railsさんはどうしてるのかなあ
どっかのライブラリに仕様を加味しつつ現実的な動作のメソッドがごそっと入ってそうだが
829:デフォルトの名無しさん
09/08/13 12:23:40
>>828
h と u については有名
ERB::Util の中に入ってる
irb> require 'erb'
irb> include ERB::Util
irb> p h('<html>')
"<html>"
irb> p u('ABCDE!,.[]123')
"ABCDE%21%2C.%5B%5D123"
フォームのエスケープとか URL のコンパクションとかやってくれるとこはまだ知らない
830:デフォルトの名無しさん
09/08/13 16:07:00
あまりにカオスだからいっそStringのメソッドに入れてしまおうか、
という話がでたくらい
831:デフォルトの名無しさん
09/08/13 16:27:39
>>830
Web特化のPHPならあり得る選択だろうけど、Rubyでやると賛否の否の方が圧倒的だろうな
なによりPHPを馬鹿にできなくなるし
832:デフォルトの名無しさん
09/08/13 16:33:11
現実の問題を解決する道具としてプログラム言語があり、
現実として Ruby が Web でよく使われているのに。
833:デフォルトの名無しさん
09/08/13 16:35:47
>>825
HTMLをエスケープするだけのためにあんなでっかいライブラリ呼んでられん
834:デフォルトの名無しさん
09/08/13 16:38:55
今はrequire 'cgi/util' するのが正解かな
835:デフォルトの名無しさん
09/08/13 17:06:57
はいはいみなさい便所の落書きお疲れ様です。
ここでなされた議論なんて一切参考にしないし
むしろ採用しないような力が働くからそのつもりでお願いしますよ。
836:デフォルトの名無しさん
09/08/13 17:26:17
議論された場所なんか関係ないね
参考にしたけりゃするし、気に入らなければしない
もちろん場所によってS/N比は違うが
837:デフォルトの名無しさん
09/08/13 17:34:00
話してるのが気に入らないって書いてる人に対して特にコメントはない
838:デフォルトの名無しさん
09/08/13 18:59:47
>>835
そうならなかったことは歴史が証明してるけどなw
老害って自分たちが苦労して堪え忍んだ不条理を
若いのがこともなげにスルーすると滅茶苦茶ヒステリックにブチ切れるよねw
いい年したオッサンの風体で幼稚極まりないのって見苦しいことこの上ないというか。
839:デフォルトの名無しさん
09/08/13 21:21:24
さすが本スレという感じの流れですね
840:デフォルトの名無しさん
09/08/13 21:42:16
>>838
ま、そのへんは回り持ちだよ。君も後にそうなる。
歴史が証明してる。
841:デフォルトの名無しさん
09/08/14 00:32:24
XML のパーサーがまだ作られていない時、
完璧なパーサーを作ろうとすると、すごく大変だけど、
90% ぐらいを満たすパーサーならば、
楽チンで作れるという話を聞いた。
その 10 % のために、コード量がすごく増えて、
労力と時間を使うのは、もったいないなーと思った。
ライブラリーは、90% を満たせる軽量なものがいい。
だいたい、残りの 10% って使用頻度が少なかったりする。
842:デフォルトの名無しさん
09/08/14 00:42:55
でも、その10%に入ってる機能の1つが必須要件に入っていたりするんだよな
843:デフォルトの名無しさん
09/08/14 04:23:10
9割で良いから。
-> 9割の物をつくる
-> 事情を知らない人が来て出来ない1割に文句を言う。
-> メンテする気がなくなる
-> 放置ライブラリができる
-> 新しいライブラリを作ろう。9割で良いから。
844:デフォルトの名無しさん
09/08/14 04:47:07
っていうか今のRubyの添付ライブラリは9割まではできてる
残り1割というが、1割というのはかなり大きい
「普通に使っていれば絶対に引っかかる」のが1割
845:デフォルトの名無しさん
09/08/14 04:52:51
使用状況を100個集めて、90個くらいまで対応して「だいたい9割できました」と言ってしまうような誤りが多い
実際に起こりうるポピュラーな使用事例は300個くらい存在するにもかかわらず、
一番最初の事例採取が間違っていたがために、実際稼動すると充足率は3割未満だ
添付ライブラリは仕様先行のほうがいいと思う
846:デフォルトの名無しさん
09/08/14 05:10:11
思ったより Ruby が急速広範に使われてしまい、
さくっとライブラリ直そうにも影響範囲がでかくなりすぎて互換性に縛られてどうにもならん
というのが現状のような気がする
Net::HTTP みたいな直し方すら、1.8.6 が広まった今ではもう危なっかしくてできん
1.6 時代ならまだがりごり直せた気がするんだが
847:デフォルトの名無しさん
09/08/14 05:21:12
いっそのこと Ruby++ とか別の言語にしてしまった方がいいのかね
848:デフォルトの名無しさん
09/08/14 05:27:57
本体添付ライブラリ は難しくても、gem なら大幅に変わっても見逃してもらえる
gem で事実上の標準ライブラリを作って本体にぶち込むんだ
849:デフォルトの名無しさん
09/08/14 06:08:08
>>848
それしかないだろうな
現状でも「アレをやる場合は添付ライブラリ駆使ではなくgemの○○が定番」というのが分野によってはあるわけだし
850:デフォルトの名無しさん
09/08/14 06:42:22
ねー
たとえばクローラ作ってたとして、HTTPS 対応みたいな、
受け取った URL によってはそもそも絶対使わないようなライブラリがけっこうある場合、
require 'net/https' if uri.scheme == 'https'
というように、メソッドの途中で条件分岐で require させるのって下品？
851:デフォルトの名無しさん
09/08/14 07:01:49
下品かといえばやっぱ下品だと思うよ
「必要なときに必要なものだけrequire」と書くと、字面はとってもエレガントなんだけどね
RMagick みたいなよっぽど重いやつでない限り、用はなくても最初に全部読むのが基本
852:デフォルトの名無しさん
09/08/14 07:01:50
Rubyは標準添付ライブラリレベルではメジャーバージョンアップごとに結構変わってる。
例えばcsvとかは1.9でFasterCSVへの入れ替えが行われてるし、test/unitもmini/testになってる。
結局不満があるのに変わらない系のライブラリは、責任持って変えようって言う人がいないだけ。
互換性は、別の名前で入れて時間をかけて置き換えっていう手もあるし、どうとでもなる
853:デフォルトの名無しさん
09/08/14 07:11:20
>>850
open-uriは正にそーゆー事をやってるね (ftp|http)
あれを下品だと思うなら下品と言ってもいいのかな
854:デフォルトの名無しさん
09/08/14 07:17:41
caseで書けそうなくらい条件と場所がまとまってて、自分以外のライブラリを呼んでるなら許すと思う
あちこちで細かく自分の下のファイルをrequireするのはやめてほしい気分
855:デフォルトの名無しさん
09/08/14 11:25:07
>>850
autoload使えば、と思ったが、
Net::HTTPSとかがあるわけじゃないのか。
856:デフォルトの名無しさん
09/08/14 20:04:46
net/httpsの中身をnet/httpに移して空にし、net/http側でautoload'openssl'したらどうだろう
857:デフォルトの名無しさん
09/08/16 02:50:52
コミケ2日目の帰路で
・RubyKaigi2009のシャツ
・NetBSDの携帯ストラップ
なんて風体の髭の人を見たんだが、
名のある開発者かなんかだったんだろうか
858:デフォルトの名無しさん
09/08/16 03:16:54
@takano32 ?
859:デフォルトの名無しさん
09/08/16 11:52:53
Rubyﾀｿの萌え萌えRuby入門でも描いて布教しろ
860:デフォルトの名無しさん
09/08/17 16:04:19
githubでフォークしたものが手元にあるんだよ
んで、手当たり次第魔改…気になっていた点を節度を持って改良したんだ
変えた点を細かく記録したコミットが30個くらい入ってるブランチになったんだ
最終的な新機能はお互いに関連する2つなんだけど、
ちょっと大掛かりだったもんで全部記録したんよ
これそのまま公開したらうざいよね？
861:デフォルトの名無しさん
09/08/17 16:08:54
興味持った香具師は粛々とpullするだろうからいいんじゃね？
862:デフォルトの名無しさん
09/08/17 16:14:47
>>860
公開するブランチはcherry-pickとスカーッシュで体裁整えるのが礼儀だろ
時々typo修正とかrevertとかマージの痕跡とか入ったままのがあるけどああいうの問題外
公開してしまったものをコミットで修正するのは仕方ないけど、公開前ならローカルで整頓
863:デフォルトの名無しさん
09/08/17 16:24:17
そのへんよくわかんないよね
commitの粒度とか
Ruby関係ないけどな
864:デフォルトの名無しさん
09/08/17 16:32:47
あー、rubygemのライブラリいじるときってさ、
ファイル追加したらManifest.txtやgemspecにも記述を追加するべきだよね？
コミットごとにCHANGELOGにコミットログをコピペするんだよね？
865:デフォルトの名無しさん
09/08/17 16:43:12
公開されているコミットは
「それだけを取り出して適用して（なおかつ衝突部分だけをなんとかすれば）なんとかなるようになっている一塊」
だから、やっぱ Manifest には書いたほうがいいんでないの
変更が必要になる場所はとにかく最低限衝突させて明示するほうがよさそうだ
rubygems ライブラリにとっての「コンパイル成功」は gem パッケージ生成だろうから
それが失敗する状態で特定のコミットが公開されているというのは片手落ちだと思う
866:デフォルトの名無しさん
09/08/17 16:51:26
commit 前に rake しろとな
867:デフォルトの名無しさん
09/08/17 17:58:46
学生が開発したコードがRubyの本体に
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
何がどう変わるのか、知ってる人教えて。
集まった学生は天才プログラマーですか？
868:デフォルトの名無しさん
09/08/17 18:06:48
Rubyがどんどんカオス化してってるな・・・
やっぱPythonにしておけばよかった・・・
869:デフォルトの名無しさん
09/08/17 18:35:54
>>868
確かに伽藍型開発であるPythonでは想像だにできない愚行だよな。
学生がソースに触れるなんておこがましいにも程がある
870:デフォルトの名無しさん
09/08/17 18:39:58
>>867
サッサーをmatzかと思っちゃった。
871:デフォルトの名無しさん
09/08/17 18:40:15
>>867
これすごいなｗ
裾野が広がって優秀なやつがバンバン育ってるんだろうな
おれは彼らの作るプログラムを利用させてもらうしかないわ
872:デフォルトの名無しさん
09/08/17 18:41:27
中学生とかもうね涙でそう
873:デフォルトの名無しさん
09/08/17 19:35:07
まあ年寄りは年の功で精査検査でがっつりツッコめばいいんだよ
それで全体のバランスが取れてうまくいくようになってる
稀～に経年知識ゼロでもセンスで綱渡りして渡り切れる若い人もいるがぬ
874:デフォルトの名無しさん
09/08/17 19:49:11
>>867
これほんとにその学生が自分で見つけてデバッグしてコード修正したの？
なんかこのセキュリティなんちゃらに箔をつけるために思えるんだけど
875:デフォルトの名無しさん
09/08/17 20:00:19
> その成果が冒頭で紹介したRuby本体の改良などである。
>開発されたコードは，ベンチマークによってはRubyの性能を約5倍向上させるもの。
>すでに笹田氏の手により，8月15日付けでRuby本体に取り込まれている
すげぇ！この前の５０倍と合わせて最大250倍も高速に！
876:デフォルトの名無しさん
09/08/17 20:02:20
「ベンチマークによっては」だけど、
通常利用でも顕著に高速化の恩恵が受けられるような改良であればいいな
おじさんは隅っこの方で君たちのお世話になりますよ
877:デフォルトの名無しさん
09/08/17 21:52:15
なんか胡散臭い記事だなw
878:デフォルトの名無しさん
09/08/17 21:54:02
おまいらの嫉妬なさけなすぎ
せめて未来ある若者の足をひっぱるなよ
879:デフォルトの名無しさん
09/08/17 21:57:20
いやそりゃある程度持ち上げてはいるだろ
凄い感じの人がいますが未来は不定だから何も凄くないんですヨ、みたいな記事に価値はねえw
それっぽく希望を膨らませる前向き記事にしてこそプロ
880:デフォルトの名無しさん
09/08/17 22:00:08
はてなとかこんなことやってないで
もっとましな有料オプション付けろよ
881:デフォルトの名無しさん
09/08/17 22:04:56
誰か試してみて速くなってた？
882:デフォルトの名無しさん
09/08/17 22:44:17
厨房の頃からrubyみたいな高級言語さわれて羨ましいな。
わしが厨房の頃はZ80アセンブリしか選択肢がなかったもんじゃ。
883:デフォルトの名無しさん
09/08/17 22:46:17
消防の頃からBasicみたいな高級言語さわってた
おいらが通るよ
884:デフォルトの名無しさん
09/08/17 22:48:10
この贅沢もんが！
というおいらは消防の授業でLOGOだったお。
885:デフォルトの名無しさん
09/08/17 22:49:54
考えることが少ない方がいいかもしれない
886:デフォルトの名無しさん
09/08/17 22:53:31
考え過ぎると禿げるしね
887:デフォルトの名無しさん
09/08/17 22:56:11
ストラウストラップが禿げてるのはそのせいか
あんな言語だもんな・・
888:デフォルトの名無しさん
09/08/17 22:59:06
考えすぎると禿げる、が真だとしても、
禿げてる人はよく考えてる、は必ずしも真ではない
何が言いたいかというと、うちの会社の禿げを何とかして欲しいと
889:デフォルトの名無しさん
09/08/17 23:00:05
つまんないよ
890:デフォルトの名無しさん
09/08/17 23:23:37
5倍速くなってV8と同等くらいになるのか
891:デフォルトの名無しさん
09/08/18 02:26:08
むしろアセンブラで組めたほうが将来は有望だろう。
rubyは数十年後には消えてる鴨だし。
892:デフォルトの名無しさん
09/08/18 06:47:06
>>858
なんとも。
とりあえずサンダル履きだったのでサークル参加だったのはほぼ間違いないかと。
893:デフォルトの名無しさん
09/08/18 07:00:51
一般参加者はスプリンターシューズを履いてるからな
894:デフォルトの名無しさん
09/08/18 10:49:19
URLﾘﾝｸ(www.infoq.com)
VC6捨てようぜ
あとライブラリ作成者はmingw32をWindowsとして扱えバカ
という話らしい
895:デフォルトの名無しさん
09/08/18 13:51:08
ついに公式ビルド元としてすら期待されなくなったか
とはいえこっちのが健全な流れだよなあ
896:デフォルトの名無しさん
09/08/18 13:54:14
できる人がリプレースというのは正しい
メンテナンス上の問題でVC6だったんだから、メンテナンス上の問題が解消できるならVC6でなくてもよい
897:デフォルトの名無しさん
09/08/18 15:51:51
>>895
> ついに公式ビルド元としてすら期待されなくなったか
なにが?
公式には
・「ruby-installer」はruby本体とは独立したプロジェクト
・「公式ビルド元」というものが存在したことはない
という答えになると思う。
898:デフォルトの名無しさん
09/08/18 17:38:59
うさビルドは9xサポートのためにVC6を使っている。
9xを切れるならばVC6以外を使った方がよい。
899:デフォルトの名無しさん
09/08/18 17:47:02
jperlみたいに残すのもありかなとも思う
古いシステム用のRuby
900:デフォルトの名無しさん
09/08/18 18:20:04
そろそろbccとかtccとかの（今となっては）マイナーなコンパイラを
切り捨ててもいいかも、ってもう切り捨てたんだっけ?
901:デフォルトの名無しさん
09/08/18 20:11:00
>>898
9xのためじゃないよ
バイナリ配布されている外部ライブラリのほとんどがmsvcrt.dllとリンクしているから
902:デフォルトの名無しさん
09/08/19 02:59:01
>>901
この辺の話かな
URLﾘﾝｸ(d.hatena.ne.jp)
URLﾘﾝｸ(www.artonx.org)
903:デフォルトの名無しさん
09/08/19 03:08:28
URLﾘﾝｸ(www.artonx.org)
の6ページ目あたりでもそんなことを話していたんだと予想
904:デフォルトの名無しさん
09/08/19 18:04:41
>>901
逆でバイナリ配布されている外部ライブラリのほとんどは
usaビルドにあわせて泣く泣くmsvcrt.dllとリンクするようにしているんじゃね。
>>894のがデファクトになればみんなあっさり移行するよ。
905:デフォルトの名無しさん
09/08/19 18:58:45
>>904
何もわかってない奴だなあ。
「外部ライブラリ」ってのはこの場合Rubyの拡張ライブラリじゃなくて、
例えばOpenSSLとかGDBMとかそのもののことだよ。
それからね、mingw版もmsvcrt.dllにリンクするんだよ。
拡張ライブラリに関してはVC6で作ったmswin版とmingw版はバイナリ互換。
906:デフォルトの名無しさん
09/08/19 19:06:57
なんでVC6なんだ
2008とか使えねーの？
907:デフォルトの名無しさん
09/08/19 19:45:55
ビルド環境変えるのが面倒だから。に30カラット。
908:デフォルトの名無しさん
09/08/19 20:31:28
唐揚げ食べたいけど食べすぎると死ぬよね
909:デフォルトの名無しさん
09/08/19 21:06:27
>>906,907
この話を最初から全部読み直せ。リンク先も辿って。
VC6以降の全てのVCはそれぞれランタイムDLLがファイル名から異なる。
Ruby本体、拡張ライブラリ、拡張ライブラリが呼び出す外部ライブラリDLL、
が全て共通のランタイムDLLにリンクされていない限り、全体としてのRubyが
正常に動作することは保証されない（たいていはクラッシュする）。
910:デフォルトの名無しさん
09/08/20 01:06:38
python2.5ってmsvcr71.dllとリンクしてんだよね。
OpenSSLとかってどうしてんだ？
自前でビルドしてんのかな。
911:デフォルトの名無しさん
09/08/20 07:45:26
>>905
>mingw版もmsvcrt.dllにリンクする
それはみんなわかってて、だからこそ
mingw版が解法だっていってるんでしょ?
・新しいVisualC++はmsvcrt.dllをリンクしてビルドしてくれない
・mingwのgccは最新でもmsvcrt.dllをリンクできる
って話で。
だからこそ、
>拡張ライブラリに関してはVC6で作ったmswin版とmingw版はバイナリ互換。
だし、それゆえ移行コストが低いからmingwにしようって話になるわけで。
912:デフォルトの名無しさん
09/08/20 08:40:12
そういえば>>894でreadlineをpure rubyなものに差し替えようとしてるのってなんでだろ
GNU Readlineがらみでなんか問題があるんだっけ
913:デフォルトの名無しさん
09/08/20 08:44:46
readlineといえばWindowsで端末の画面サイズをirbに
（というかreadlineに）教えるにはどうすればいいんだろ
cmd.exeの画面サイズを30x120とかにしてると
補完とか改行周りが悲しいことになってかなわん
914:デフォルトの名無しさん
09/08/20 08:57:31
テラ自己解決しました
URLﾘﾝｸ(d.hatena.ne.jp)
915:デフォルトの名無しさん
09/08/20 09:03:01
>>912
readlineはGPLだから、組み込んだ時点でRubyライセンスが不可になってGPL一択になってしまうこと
Gauche の gosh （irb 相当）が Readline をサポートしないのも同じような理由だと思った
916:デフォルトの名無しさん
09/08/20 11:54:47
>>914
考えようによっては修正がupstreamに取り込まれないまま
数年経っちゃってるともとれるなあ
だれか拡張ライブラリ直す形のコードにしてパッチ投げない?
それかmputたんのgithubにpull requestしたほうがいいのか?
917:デフォルトの名無しさん
09/08/20 12:52:23
_whyが行方不明らしいな。
918:デフォルトの名無しさん
09/08/20 13:33:47
最近、どこかのスレで同じ話題を見た気がするけど
mingw環境でtcltklib.so（stub有効）がコンパイルできない……
解決法を知ってる人がいれば教えてほしい
環境：
ruby 1.8.7-p174, ActiveTcl 8.5.7.0
stub無効ならコンパイルできる