[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2chのread.cgiへ]
Update time : 05/09 23:24 / Filesize : 165 KB / Number-of Response : 828
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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



1 名前:デフォルトの名無しさん mailto:sage [2009/07/25(土) 11:03:24 ]
最強のLL=軽量プログラム言語は、どれよ?

エントリーは、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バトルロワイヤル2【Ruby,Python】
pc11.2ch.net/test/read.cgi/tech/1209289408/
【Perl,PHP】LLバトルロワイヤル【Ruby,Python】
pc11.2ch.net/test/read.cgi/tech/1188997302/

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
誤解じゃねーよw

俺がいいたいのは問題起こすPython製アプリの話と、それが原因となっている言語の問題。
プログラマの心遣いとかの話じゃない。

逆に、.NETアプリはマルチバイトで問題起こすの見たことない。
UNICODE前提のせいかしらんが・・・(.NETの仕様はあまり知らんので俺に突っ込みされても困るけど)

>>584
あー、そういや、>>573でRubyって書いたけど、コマンドプロンプトと文字コードの相性最悪なの忘れてたわw
UTF-8でRSpecとautotest(autospec)でまともにテストもできないwww
俺は出力時にSJISに変換してるw

>>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
もしかして、プログラマ性善説主義者か?お前w

そんなのは言語仕様のレベルで都合のいい方向に傾けておくべきこと。

プログラマーなんて信用しちゃいけないよ。
あのリーナス・トーバルズすら、エンコーディングに無関心なのか 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
「俺が」じゃなくて、海外のアフォどもがなw

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組み込みにくいってよwww死亡確認ww

637 名前:デフォルトの名無しさん mailto:sage [2009/10/17(土) 15:15:50 ]
VisualStudioとかに慣れてて、php仕事に移行して何がつらかったってprintfデバッグだったわw
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 ]
デバッグの話が出てるけど、
バグ潰しって普通テスト書くもんじゃないの?

655 名前:デフォルトの名無しさん mailto:sage [2009/10/18(日) 20:07:31 ]
初心者だから、普通がわからん!!

656 名前:デフォルトの名無しさん mailto:sage [2009/10/18(日) 20:13:41 ]
テストって言っても、ウェブの場合、結局ブラウザ通さないとダメでしょう。処理が複雑な場合は、セレニウム使ってる。簡単なのは目視。

657 名前:デフォルトの名無しさん mailto:sage [2009/10/18(日) 20:17:00 ]
>>655
意味が分かる前にやめておけw 全然すすめられない。

知ってはいたけどブラウザー依存はかなり多いのね。特にjavascript。
Firefoxだけ解釈が違うものがいくつかあって、対応しなくてもいいことになったが、今後の事を考えると怖い。

658 名前:デフォルトの名無しさん mailto:sage [2009/10/18(日) 20:40:36 ]
テストをすすめない?なぜ?

659 名前:デフォルトの名無しさん mailto:sage [2009/10/18(日) 21:35:45 ]
いや、仕事として薦めないってだけ。
テストはやらなあかん。

660 名前:デフォルトの名無しさん mailto:sage [2009/10/18(日) 21:39:40 ]
友愛とUIを掛けてるのか



661 名前:デフォルトの名無しさん mailto:sage [2009/10/19(月) 00:47:19 ]
つーか、テストってそういう環境依存テストばっかりだからなw
LL使うような仕事はw

662 名前:わかんないんです(><) ◆WAkan9Ey1g mailto:わかんないんです(><) [2009/10/19(月) 02:08:31 ]
わかんないんです(><)






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

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<165KB

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