【Perl,PHP】LLバトルロワイヤル7【Ruby,Python】

1 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 11:03:24 ] 最強のＬＬ＝軽量プログラム言語は、どれよ？ エントリーは、Perl、PHP、Python、Ruby、JavaScript・・・ さあ、死ぬまで語りやがれ！！！ ■LLとは？ 軽量プログラミング言語（Lightweight Language,LL）とは、取り回しに優れ、 コードの作成や修正が容易と見なされるプログラミング言語のことを指す。 ここでいう「軽さ」はプログラマの負担の軽重を指し、 実行速度に優れているという意味ではない。 現在の水準では ・インタプリタ ・動的型 ・正規表現 ・関数オブジェクト などを利用できるものがLLと呼ばれることが多い。（Wikipediaより） ■過去スレ 【Perl,PHP】LLバトルロワイヤル6【Ruby,Python】 pc12.2ch.net/test/read.cgi/tech/1244166510/ 【Perl,PHP】LLバトルロワイヤル5【Ruby,Python】 pc12.2ch.net/test/read.cgi/tech/1238720336/ 【Perl,PHP】LLバトルロワイヤル4【Ruby,Python】 pc12.2ch.net/test/read.cgi/tech/1234635513/ 【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】 pc11.2ch.net/test/read.cgi/tech/1215319832/ 【Perl,PHP】LLバトルロワイヤル２【Ruby,Python】 pc11.2ch.net/test/read.cgi/tech/1209289408/ 【Perl,PHP】ＬＬバトルロワイヤル【Ruby,Python】 pc11.2ch.net/test/read.cgi/tech/1188997302/ 554 名前：デフォルトの名無しさん mailto:sage [2009/10/11(日) 11:54:19 ] つか、んなもん使ってる業務あるんだｗ 555 名前：デフォルトの名無しさん mailto:sage [2009/10/11(日) 12:34:03 ] AccessのVBA部分にパスワード掛けるってのはダメなの？ 556 名前：デフォルトの名無しさん mailto:sage [2009/10/11(日) 12:34:31 ] Accessでももう少しマシなアクセス権管理できなかったか 557 名前：デフォルトの名無しさん [2009/10/11(日) 12:40:40 ] アクセスできるからAccessなのにアクセスできないAccessなんかNon-Accessだろ。 558 名前：デフォルトの名無しさん mailto:sage [2009/10/11(日) 12:57:28 ] いやそういうのはいい。 559 名前：デフォルトの名無しさん mailto:sage [2009/10/11(日) 14:02:26 ] mde 560 名前：デフォルトの名無しさん [2009/10/11(日) 16:34:35 ] どうしてこうなった 561 名前：デフォルトの名無しさん mailto:sage [2009/10/11(日) 19:38:20 ] >>557 俺は評価する 562 名前：デフォルトの名無しさん mailto:sage [2009/10/11(日) 22:10:49 ] >>527 wxPython は独立したコマンドじゃくてスクリプトに取り込むモジュールだ。今のOSXには最初から入ってる。 wxRuby も似たような感じだろう。 Perlの場合は wxPerlっていう別コマンドでないと実行できないんだな。 563 名前：デフォルトの名無しさん mailto:sage [2009/10/12(月) 20:11:45 ] だからperlで十分だっての 564 名前：デフォルトの名無しさん mailto:sage [2009/10/12(月) 21:39:29 ] PHP、割りと嫌いじゃない 565 名前：デフォルトの名無しさん mailto:sage [2009/10/12(月) 23:09:59 ] 俺も。 というかC使いとかの人は一番慣れやすい。 PHP使いはウェブPHPで、他はC/C++でとか両刀的な人が多いけど Ruby/Python使いは割となんでもこれ一つでやる、って人が多いな。 566 名前：デフォルトの名無しさん mailto:sage [2009/10/12(月) 23:26:20 ] Ruby、Python、どっちが日本語対応が良いの？ 567 名前：デフォルトの名無しさん mailto:sage [2009/10/12(月) 23:36:16 ] >>565 それはPHPがWeb以外にむいていないから。 まあ真のPHP厨はなんでもPHPでやろうとするけど。 568 名前：デフォルトの名無しさん mailto:sage [2009/10/12(月) 23:37:17 ] >>563 十分って言い方だと、Perlは劣っている前提みたいにならないか？ 569 名前：デフォルトの名無しさん mailto:sage [2009/10/12(月) 23:38:18 ] >>566 Python 570 名前：デフォルトの名無しさん mailto:sage [2009/10/12(月) 23:39:17 ] Perlは劣ってるっての 571 名前：デフォルトの名無しさん mailto:sage [2009/10/12(月) 23:43:06 ] そういうことにしたいのですね。 572 名前：デフォルトの名無しさん mailto:sage [2009/10/12(月) 23:59:44 ] そういうこと 573 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 08:00:41 ] >>566 Ruby Pythonのソフトはいつもマルチバイトがらみでトラブル起こす。 574 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 08:05:21 ] そうでもない。 Pythonでトラブルが起きるのはプログラマが正しい使い方を分かってないから。 （日本では少ないが欧米だとそれなりに経験のあるプログラマでもバイト列と文字列の区別のついていない人が結構いる） 少し前だったが、俺が各言語でのファイルシステム関連の多言語対応状況を調べたときはPyhtonが一番よくできていたと思う。 次点でrubyだったがUnicodeのファイル名の扱いに若干難があった。PHPとPerlはもはや論外。 575 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 08:11:34 ] 欧米というか特にアメリカ人な。 本当にZの後に文字がないと思ってるんじゃないかって連中が存在する 576 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 08:17:21 ] Pythonの「暗黙に失敗するよりも明示的にエラーになるほうがいい」というルールが 結果的に >>573 みたいな印象を受けている。 UnicodeEncodeError, UnicodeDecodeError はPythonで頻繁に見る ことになるエラーだけど、文字コードに関する設計ポリシーを持ったときにこのエラーは ポリシー違反している箇所を報告してくれる頼もしい見方になる。 中途半端にうまく動いていくれる代わりに、ShiftJISのファイルの中にUTF-8が混じる ことがあるのに比べるとPythonの方が安心できる。 577 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 09:18:33 ] >>574 なんでPerl論外なん？ 578 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 10:30:26 ] >>577 (少なくとも)ActivePerlがファイルを開く際にCreateFileAをうちぎめで使ってるので移植性を考えると避けたい。 ファイル名として与える文字列にUTF-8フラグ立てても変わらない。カスすぎる ちなみに、PHPはファイル名を文字列と見なしていないので、 自分でファイル名をShifit_JISとかにエンコードする必要がある。 もはやウンコのレベル 579 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 12:33:10 ] >>566 Rubyい一票 580 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 13:21:09 ] >>578 Windows限定で、日本語ファイル名限定かよ。 581 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 14:04:04 ] >>579 RubyはPythonみたいにCreateFileWを使ってくれるん？ >>580 日本語というか、Unicodeファイル名だな。 W系APIを使っている=Windowsでの動作がきちんと考えられていると 判断されても仕方ない。 582 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 15:41:36 ] >>573 >Pythonのソフトはいつもマルチバイトがらみでトラブル起こす。 それは誤解 漏れもpython初心者の頃はなんだこりゃと思っていたが 理由がわかるとちゃんと使えるしよくできてる 583 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 15:45:37 ] windows のコマンドプロンプト はやく UTF-8 に対応してくれないかなぁ 584 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 15:47:55 ] >>583 一応 chcp 65001 したら utf-8 になるけど、問題が多すぎて使い物にならないね。 WriteConsoleW を使って utf-16 を出力できるようにするのが一番いいんだろうけど、 あまりにも標準入出力の概念からずれるから、sys.stdout.write()を置き換えるのは 難しい。結局、 pywin32 の console を使うのが正解だと思う。 585 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 18:48:59 ] >>584 標準入出力にUTF16はよくないのでは。 ASCII互換じゃないし、表現できない 文字があるでしょ。 586 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 19:08:47 ] >>585 WindowsのW系APIが受け取る文字列がUTF-16だから、UTF-16で表現できない 文字列はそもそもWindowsが表示したりファイル名に使ったりできない文字列だよ？ 587 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 21:10:08 ] perlは、windowsで使わない！！ それでよし！ 588 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 21:43:11 ] そーだ。perl以外は、いらん！ マルチバイト処理もEncode覚えれば不自由ないし。 589 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 22:24:16 ] >>583 PowerShell標準で付くんだから、必要ないだろ ISEもあるんだし 590 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 22:24:43 ] 使いたいの使えばいいじゃないか じゃ話が終わるので、 負荷を心配しないである程度大きめなものを、急いで作りたいなら、Railsが使えるRuby 負荷を気にしたり、高速に作りたいなら、Perl 「俺Python使い」と、かっこつけたいなら、Python 外注に安く作らせたいなら、PHP 591 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 22:26:47 ] 外注に安く作らせるならPHP。 それ以外は全部PythonとC。 592 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 22:48:33 ] >>582 誤解じゃねーよｗ 俺がいいたいのは問題起こすPython製アプリの話と、それが原因となっている言語の問題。 プログラマの心遣いとかの話じゃない。 逆に、.NETアプリはマルチバイトで問題起こすの見たことない。 UNICODE前提のせいかしらんが・・・（.NETの仕様はあまり知らんので俺に突っ込みされても困るけど） >>584 あー、そういや、>>573でRubyって書いたけど、コマンドプロンプトと文字コードの相性最悪なの忘れてたわｗ UTF-8でRSpecとautotest(autospec)でまともにテストもできないｗｗｗ 俺は出力時にSJISに変換してるｗ >>589 PowerShellだと文字コード周り解決するのか？ちょっと入れてみるか 593 名前：デフォルトの名無しさん mailto:sage [2009/10/13(火) 22:59:21 ] >>592 > プログラマの心遣いとかの話じゃない。 プログラマの心遣いの問題ですね CでUnicode対応アプリも書ければ、いわゆる「駄目文字」で問題を起こすアプリも書けるのと同じ ただ、Javaや.NETのようにテキスト＝Unicodeと割り切ったほうが 心がけの悪いプログラマでも問題を起こしにくいのは確かで Pythonも3.xからはそうなりました 594 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 01:11:57 ] Java/C# 　　内部エンコーディングUTF16で固定。入出力時に外部エンコーディング指定して必ず変換。 Python 　　uを付けた文字列はUTF16固定。付けないと任意？設定だっけ？内部的に混在するので扱い注意。 Perl 　　Cと同じで任意だっけ？wideはなしだっけ？ こんなんだっけ？もう面倒だし、Java/C#式の内部固定がぐちゃぐちゃにならなくて一番いい気がするけどどうなん？ 595 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 02:03:55 ] >Python >　　uを付けた文字列はUTF16固定。付けないと任意？設定だっけ？内部的に混在するので扱い注意。 >付けないと任意？設定だっけ？ ソースの先頭2行目に # -*- coding: utf-8 -*- などと書くと そのコードでエンコードされたバイト列になる >内部的に混在するので扱い注意 混在っつっても明示的にuが付いてる訳でそこは平気 どっちかというとprintでuの付いている文字列を出力すると 暗黙にデフォルトのエンコードに変換されてコンソールに出力されるが pythonに慣れずに(perlとかと同じ感覚で)ごっちゃにしたバイト列の方をprintすると よくここでエンコードエラー/デコードエラーになる つまり文字列とバイト列の違いは意識する必要がある あとpython3で改善されてるはず 596 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 02:07:00 ] >>595 >あとpython3で改善されてるはず だからといって 2.4.x - 2.6.x が劣ってる訳じゃないけどね 2.3.x 以下は糞 597 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 03:58:10 ] >>593 もしかして、プログラマ性善説主義者か？お前ｗ そんなのは言語仕様のレベルで都合のいい方向に傾けておくべきこと。 プログラマーなんて信用しちゃいけないよ。 あのリーナス・トーバルズすら、エンコーディングに無関心なのか git がマルチバイトを考慮しない仕様(バイナリとして扱う) 心遣いの問題とか言いいながら、永遠にマルチバイト対応がクソなC言語製やPythonアプリでも使ってろや 598 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 04:01:39 ] >永遠にマルチバイト対応がクソな kwsk 599 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 08:45:26 ] 597は言語がサポートしてないとなにもできない厨。 600 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 09:19:42 ] いや、gitは確かにウンコ。 これはリーナスのおっさんが新しい方式について行けない老害だったから。 hgもウニコードの扱いが糞で、これもプログラマのセンスがなさ過ぎる。 Python3の文字列にバイナリとしてアクセスする方法をよこせなどと言っていた。 一方bzrは同じPythonだが上二つと比べて格段にエンコーディング周りのポリシーが優れてる。 601 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 09:29:19 ] >>594 uがついたのが文字列で、ついてないのはバイト列。 世の中には、どうしてかこれを区別できない連中が多すぎる。 602 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 09:38:09 ] uがついてるのはリテラルのときじゃね？ str = u"ahoaho" ってしたらstrがなにかわかんなくね？ 603 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 09:41:41 ] 正直スクリプトはこの辺がごちゃごちゃしすぎてて全然LLじゃねー Javaのがはるかに楽 604 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 09:47:00 ] >>602 その場合strの値はunicode型で、uをつけなかったときはstr型になる。 型が違うと当然、相互の演算に制約を受ける。 605 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 09:50:15 ] Pythonの型付けは強い方だから、perlやPHPに慣れてる人だと引っかかるのかもしれないね 606 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 10:09:01 ] JavaはcharがUCS2だと割り切っただけだろ。 サロゲートペアで泣きを入れることになっても知らんぞ。 607 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 10:11:23 ] >>606 ユニコード操作するときってサロゲートペアはあんまり気にならないものだよ。 UTF32でも結局のところ合成文字を考えないといけなくてコード単位ごとに処理できない 608 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 10:17:29 ] Pythonは2.6でも from __future__ import unicode_literals したら、 "foo" が unicode になって、代わりにバイト列は b"foo" しないといけないようになるよ。 609 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 16:23:55 ] WindowsでPerlは確かにCreateFileAなのがダメだ。 Win32API::FileのCreateFileWを使えば簡単に呼べるんだが Windows用のコードが増えちゃう。 decodeされてる文字列がそのまま、ファイルテスト演算子やPath::Class, IO::All等で使えるといい。 現状そうなっていないので、B::Hooks等を使って作ろうと考えたが時間がとれん。 PerlIO::fseは今一歩だ。 でも、だれかがやってるれるんじゃなかろうか。 現状はencode("cp932", "...")渡してる。 610 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 18:17:53 ] >>566 1.9ならRuby圧勝だが、1.8ならPython勝利。 611 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 19:14:12 ] pythonのバージョンは？ 612 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 19:29:37 ] 具体的にRuby 1.9はPython2/3に比べて何がいいの？ 613 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 19:33:36 ] 全然使ってる人がいなくてかっこいい 614 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 19:50:52 ] 後発組だけあって、いいとこ取りが可能 615 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 19:55:25 ] そんな抽象的な発言はいいから、具体的に何がPythonよりも優れているの？ Python/Java/.NET の文字列=Unicode方式は十分ベターな解として 受け入れられていると思うんだけど、それよりも良い物なんだよね？ 616 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 20:05:13 ] 文字列のインスタンス毎にコードセット情報が付いていて、 言語やライブラリはコードセットについて暗黙の前提を一切持ってない。 プログラム本体が基本的に使う文字コードはUTF-8だけど、2ちゃんねるの datファイルを扱うクラスの中だけはShift-JISに、とかそういう設計が普通に できる。 コードセットインディペンデントと言って、一昔前に文字コードに興味のある Unix屋が集まれば必ず、理想の処理方式として話題になった方式なんだが。 617 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 20:08:49 ] 結局、標準ライブラリ内に文字エンコーディングに関する情報をばらまかないといけない不便な方式。 618 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 20:13:11 ] perl以外の言語の必要性が分からん！ 619 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 22:02:28 ] JavaはBOMをゴミ扱いするのが嫌 620 名前：デフォルトの名無しさん mailto:sage [2009/10/14(水) 22:04:35 ] javaってLLか？ 621 名前：デフォルトの名無しさん mailto:sage [2009/10/15(木) 00:07:08 ] objectです 622 名前：デフォルトの名無しさん mailto:sage [2009/10/15(木) 00:13:54 ] primitiveもあるから 623 名前：デフォルトの名無しさん mailto:sage [2009/10/15(木) 01:14:20 ] Python3 > Ruby1.9 = Python2.6 > Python2.5 > Python2.4 > Ruby1.8 > Python2.3 624 名前：デフォルトの名無しさん mailto:sage [2009/10/15(木) 10:47:26 ] Curl 625 名前：597 mailto:sage [2009/10/15(木) 13:50:49 ] >>599 「俺が」じゃなくて、海外のアフォどもがなｗ 626 名前：デフォルトの名無しさん mailto:sage [2009/10/16(金) 12:25:40 ] 求人でRUBYとPHPで検索かけたらPHPの圧勝。 627 名前：デフォルトの名無しさん mailto:sage [2009/10/16(金) 12:42:41 ] そりゃ求人ページが.phpなだけ。 628 名前：デフォルトの名無しさん mailto:sage [2009/10/16(金) 15:02:25 ] それだけ需要が有るって事じゃね？ RUBYよか。 629 名前：デフォルトの名無しさん mailto:sage [2009/10/16(金) 18:31:21 ] COBOLみたいな人気だよな。どう見ても 630 名前：デフォルトの名無しさん mailto:sage [2009/10/16(金) 22:24:06 ] COBOL　W 631 名前：デフォルトの名無しさん mailto:sage [2009/10/16(金) 23:27:19 ] php きらいだが、php + netbeans 便利だな。 632 名前：デフォルトの名無しさん [2009/10/17(土) 03:08:14 ] どの辺が？ 633 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 09:24:43 ] ↑ リモートデバッグっていうやつ perl cgiでできんのかな 634 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 09:32:21 ] printデバグ + tail -f でそれほど困らないと思うのだが サーバで動くアプリでデバッガって、どうやったって面倒くささが先に立つような 635 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 10:11:30 ] php 大きらいだが、php + netbeans は、わりと面倒ではなかったよ。 しかし、printデバグ + tail -fで十分だな 636 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 15:13:07 ] mixi Engineers’ Blog ≫ Lua on Tyrant: DBサーバにLLを組み込む alpha.mixi.co.jp/blog/?p=236 LL？Python？Rubyと思ったら ↓ Luaでした Python、Ruby組み込みにくいってよｗｗｗ死亡確認ｗｗ 637 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 15:15:50 ] VisualStudioとかに慣れてて、php仕事に移行して何がつらかったってprintfデバッグだったわｗ DOS時代から入ったけど、その時すでにIDEだったからprintfデバッグなんて、perlでCGI(笑)作ったときくらいしかやったことなかたからひどかった しかも、phpの挙動不審さが輪をかけてた 今なら、NetBeansでデバッグできるのか・・・ 今度試すか 638 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 15:23:23 ] 俺はそもそもあんまりバグ無いからなあ・・・ 639 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 15:40:53 ] ttp://hellopython.wordpress.com/2009/10/08/interview-with-python-3 Python△ 640 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 18:34:41 ] >>636 そもそもが組み込み向けのLuaやスクワールと比べたらなあ… 641 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 19:05:53 ] >>638 そういう問題じゃないだろ あろうがなかろうが、やらなきゃならん。普通は。 642 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 23:22:11 ] GUIのあるアプリケーションだとIDEがあった方がいいけど、ウェブならテキストエディタとprintデバッグで十分だろ。 643 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 23:31:11 ] う、うん……(´・ω・｀) 644 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 23:38:39 ] >>641 バグがないのになにをデバッグすんだよ 645 名前：デフォルトの名無しさん mailto:sage [2009/10/17(土) 23:41:37 ] >>644 デバグは、バグを探すことも含んでるよ 646 名前：デフォルトの名無しさん mailto:sage [2009/10/18(日) 02:16:10 ] デハゲしたいわ 647 名前：デフォルトの名無しさん mailto:sage [2009/10/18(日) 10:36:26 ] GUIもCUIも関係無いだろ。 648 名前：デフォルトの名無しさん mailto:sage [2009/10/18(日) 13:26:25 ] ああ、でもJavaScriptの場合、IDEがあった方がいいな。IDEというか、Firebugみたいなツール。サーバサイドの場合、高度な仕組み用意するまでもないからな。 649 名前：デフォルトの名無しさん mailto:sage [2009/10/18(日) 15:06:29 ] eclipse + EPIC は、使い物になるのか？ 650 名前：デフォルトの名無しさん mailto:sage [2009/10/18(日) 15:26:45 ] とりあえず、本当にデバッガがないと困るって人はこれくらいやってるんだろうか ttp://0xcc.net/blog/archives/000162.html Eclipseのプラグインとかで使いやすくなってそうな気もするが、そういうのは無いのかな 651 名前：デフォルトの名無しさん mailto:sage [2009/10/18(日) 15:56:22 ] あたし学生だけど、仕事現場ってxUnitつかわないの？ 652 名前：デフォルトの名無しさん mailto:sage [2009/10/18(日) 15:56:50 ] >>649 GUIでデバッグができるので重宝してるよ 653 名前：デフォルトの名無しさん mailto:sage [2009/10/18(日) 17:18:23 ] >>651 千差万別。このスレの話題でも出てたように、コンソールでtail -fしかデバッグ環境が無いものもある。 654 名前：デフォルトの名無しさん mailto:sage [2009/10/18(日) 18:30:04 ] デバッグの話が出てるけど、 バグ潰しって普通テスト書くもんじゃないの？

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef