PHPとかいうWeb界最強の言語

このエントリーをはてなブックマークに追加
1デフォルトの名無しさん
PHP使用者を馬鹿呼ばわりしたり無能扱うする輩の言葉が
嫉妬や負け犬の遠吠え程度にしか聞こえない件
2デフォルトの名無しさん:2013/03/21(木) 23:32:55.40
< `∀´>ニダー
3デフォルトの名無しさん:2013/03/21(木) 23:34:05.98
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

                  京都大学霊長類研究所
4デフォルトの名無しさん:2013/03/21(木) 23:34:40.83
      ____∩_∩
  〜/        ・ ・\
   (          ∀   )  <ぼく、4ゲット君
    \/\/\/\/
5デフォルトの名無しさん:2013/03/21(木) 23:36:54.06
ちょっと旬が過ぎちゃったけどココらへんに
増田かtogetterあたりで絡んででキャッキャウフフしてくるといいと思うよ
http://blogs.itmedia.co.jp/fukuyuki/2013/03/php-57de.html
http://b.hatena.ne.jp/entry/blogs.itmedia.co.jp/fukuyuki/2013/03/php-57de.html
6デフォルトの名無しさん:2013/03/22(金) 00:40:57.84
こっちでやれ

Phalanger 〜まさかのPHP派生言語〜
http://toro.2ch.net/test/read.cgi/tech/1363684895/
7デフォルトの名無しさん:2013/03/22(金) 02:21:01.47
webでやれ
8デフォルトの名無しさん:2013/03/22(金) 02:46:16.71
最強の言語はPythonだよ
9デフォルトの名無しさん:2013/03/22(金) 05:15:37.09
【相談】11才女子小学生ですが、これから彼氏と初体験します。皆さんのアドバイスを下さい。
http://engawa.2ch.net/test/read.cgi/jobs/1362753676/
10デフォルトの名無しさん:2013/03/22(金) 05:27:48.99
質問失礼します。
phpで動的に生成したhtml(js含む)を暗号化するライブラリを探しています。
「サーバサイドSHTML for PHP」というツールを見つけました。
やりたい事はまさにコレなのですが、とある事情により組み込めませんでした。
他にライブラリは無いでしょうか?スレ違いだったらすいません。
よろしくお願いします。
11デフォルトの名無しさん:2013/03/22(金) 09:34:17.21
12デフォルトの名無しさん:2013/03/22(金) 11:40:19.61
>>10
懐かしいですね。

まず、IEならメニューの「開発者ツール」
Firefoxなら「Firebug」
Chromeなら「デベロッパーツール」
を起動してみてください。

これらはソースコードを見ようとする人なら、だれでも知っていて使っているツールです。
何が出来るかというと、htmlやjsの開発の補助ですね。つまり解析もできます。

何が言いたいかというと、暗号化するライブラリは
標準でブラウザに搭載されている機能を使えば
簡単に暗号解除できるということです。

だから今は全く意味がありませんね。ということで懐かしいですねw
1310:2013/03/22(金) 14:39:02.59
>>11
どうやら板違いだったようですね。
失礼しました。
URL先で再度質問してみます。
ありがとうございます。

>>12
全く意味がないとは思いません。
ハッカーには色んなレベルの人がいて、
右クリックできないから諦める低レベルの人もいれば、
デベロッパーツールで解析したもののjsでやっているPOST先が分からずにあきらめる人、
WireSharkでPOST先とPOST内容を突き止める人、さまざまです。
安全性を少しでも高めるために、やっておいた方が良いものは全てやるつもりです。
14デフォルトの名無しさん:2013/03/22(金) 16:13:58.87
WireSharkなんかイラネーよ。
POST先、POST内容なんて
普通にブラウザの開発者ツールで見れるだろ。
15デフォルトの名無しさん:2013/03/22(金) 16:21:31.56
>>13
全く意味がありません。

ソースコードを見れる人は、
だれでも知っていることです。

それはハッカーではありません。

ソースコードを見ようとする人=ソースコードを理解できる人が持っている最低レベルの技術です。
誰からソースを隠そうとしてるのですか?

ソースコードを理解できない人には隠す意味はありませんよ。
ソースコードを理解できる人は全員知っていますよ。

あなたがPOST先を調べるために、WireSharkが必要になると思ってるぐらいの初心者だってことはわかりました。
POST先も内容も、ブラウザのログにしっかり表示されます。
16デフォルトの名無しさん:2013/03/22(金) 16:47:59.57
>>14
>>15
ハッカーって言っちゃったからまずかったですね。
すいません。

安全性を"少しでも"高めるためにやろうとしています。
難読化でbotはブロックできます。
レベルの低いハッカーもブロックできます。

ご存じの通り難読化はgoogleでも採用されている防御策です。
どんなケースでも全く意味のないものと言いきれますか?
その根拠はなんでしょう?

これなら板違いじゃないですよね?
17デフォルトの名無しさん:2013/03/22(金) 17:25:24.10
>>16
Googleが採用しているのは難読化ではありません。
少しでもサイズを減らすための圧縮、最適化です。

そのためのツールをGoogleは無料で公開しています。
もちろん”難読化ツール”などとは言っていません。

そして難読化は解除するためのツールがあります。(正確には圧縮されたコードを整形するもの)
http://kachibito.net/useful-resource/online-javascript-beautifier

> どんなケースでも全く意味のないものと言いきれますか?
おかしいですね。安全性を"少しでも"高めるためと言ったじゃないですか。
安全性を高めるために意味が無いと言い切れます。

POST先と内容がすぐに分かることをさっき説明したじゃないですか?
右クリック禁止=開発者ツールで突破、コピー禁止=開発者ツールで突破、
難読化=解除ツールがある。他に何の安全性を高くしたいのですか?
目的が安全性を高めるためであるなら、正しいセキュリティ技術を身につけてください。

まあ、ダメな方向へのケースでは意味があるでしょうねw
18デフォルトの名無しさん:2013/03/22(金) 17:45:32.53
>>17
obfuscateでググったらヒットしたけど?

https://developers.google.com/web-toolkit/doc/1.6/FAQ_DebuggingAndCompiling
> Why is my GWT-generated JavaScript gibberish?
>
> By default, GWT obfuscates the JavaScript it produces.
19デフォルトの名無しさん:2013/03/22(金) 17:48:40.43
>>18
ダウンロードサイズを減らすためですねぇ。
それがどうかしましたか?
20デフォルトの名無しさん:2013/03/22(金) 17:51:02.12
>>19
> This is partly done to protect the intellectual property of the application you develop
ってあるけど?
2110:2013/03/22(金) 17:51:09.05
>>17
>Googleが採用しているのは難読化ではありません。
難読化の目的は全くなかったと?

>他に何の安全性を高くしたいのですか?
ではもう一度書きますけど、難読化でbotはブロックできます。
レベルの低いハッカーもブロックできます。

>>17ではbotの指摘が抜けています。
botは取り上げなかったので一理あると思ったのでしょう?

難読化されたページではbotによる被害がほどんどありません。
よって難読化はセキュリティ的に少しだけ有効です。
(何も無い状態よりはマシという程度ですが)
22デフォルトの名無しさん:2013/03/22(金) 17:54:51.31
> 難読化の目的は全くなかったと?
だって難読化って解除できるじゃんw

天下のGoogleが解除できるのに
対策しないと思いますか?

botによる被害を防ぎたいのなら
画像にすれば済むことです。
23デフォルトの名無しさん:2013/03/22(金) 17:56:44.71
>>20
partly ってかいてあるだろ?
メインの目的じゃないよ。
圧縮するために読みにくく(obfuscate)なってしまうってだけ。

それで何かを守れるなんてGoogleは保証していない。
2410:2013/03/22(金) 17:58:29.40
>>22
bot対策として画像にすれば確かに堅くできますが、トラフィック的に採用できません。

bot対策として難読化は意味が全く無いものでしょうか?
25デフォルトの名無しさん:2013/03/22(金) 18:02:27.19
「サーバサイドSHTML for PHP」のデモページでfirebug使おうとしたら
「Firebugの無効化のお願いとその方法について」ページに飛ばされてクソ吹いたw
ブラウザの「戻る」をクリックしてもまたそのページに飛ばされる。
確かにこいつの妨害力はすごいかもしれんw
26デフォルトの名無しさん:2013/03/22(金) 18:06:13.70
>>23
何と戦ってるのか知らないけど、to protect the intellectual property of the application you develop
って書いてるじゃん。

> 圧縮するために読みにくく(obfuscate)なってしまうってだけ。
これがメインの目的とも書かれてない。

> but also because obfuscation reduces the size of the generated JavaScript files
but alsoだし。

> それで何かを守れるなんてGoogleは保証していない。
そんなこと俺言ってないし。

あと、GoogleがWebレスポンスの高速化に力を入れてるのは別の方向じゃないか?
今ならmod_pagespeedとして提供されてる奴。
27デフォルトの名無しさん:2013/03/22(金) 18:08:07.60
mod_pagespeedがやってることはここ読めばわかる。
http://web-tan.forum.impressrd.jp/e/2012/11/27/14218

jsのminifyなんて微々たるもんだよ。
28デフォルトの名無しさん:2013/03/22(金) 18:13:35.59
GoogleのClosure Compilerのことを言ってるなら、あれもトークンを書き換えるから難読化ツールだな
2925:2013/03/22(金) 18:21:45.97
「サーバサイドSHTML for PHP」 → ページ内容の文字列をエンコードしてjavascriptで書き込む
google → 空白、改行、コメントを除去する
30デフォルトの名無しさん:2013/03/22(金) 18:32:46.58
ほー、クライアントでdecodeする仕組みなのか
そのdecodeするコードを直接実行したら復元できてしまう気がするのは素人のあさはかさか?
3110:2013/03/22(金) 18:42:05.61
セキュリティのための難読化に関しては賛否両論があるみたいですね。
しかしbotに対しては、ある程度有効って事で良いですよね?
つまり、この話私の勝ちです。(勝利宣言)
32デフォルトの名無しさん:2013/03/22(金) 18:49:05.34
>>10
HTMLソースの難読化だけにピントを当てるとgoogleのはbot対策だとかそういうことに対して全く効果は無い。
結局htmlタグとかそのまま書いてあるわけだから。
>>10で例示した製品は難読化以外の妨害工作込みだから、それはそれで評価するべきだろう。
また、その製品を使ったページがfirebugで見れなくてもfirefoxにデフォルトで付属してる開発ツールで問題なく解析できたりするから、
htmlの難読化には焼け石に水程度の効果しか期待はできない。

また、ボットはhttpリクエストのログを解析すれば作れるわけで、html自体を参照する必要すらない。
もっとも、ネット中をクロールしながらhtmlを解析してあらゆるフォームに不正値叩き込んでくるボットを想定しているのなら、
頭の悪いボットはjavascriptを理解しないからおそらく何もせずに帰っていくだろう。

開発ツールもまともに使えない頭の悪い悪人の足切りに
htmlソースの難読化が有効かどうかに関してもおそらく有効だろう。


結論として難読化に多少の効果はあると思うけど、それよりも重要度の高い対策ががたくさんあるわけで、
まずそっちをやったのか確認したいところ。

安全なウェブサイトの作り方 - 独立行政法人 情報処理推進機構 セキュリティセンター
http://www.ipa.go.jp/security/vuln/websecurity.html
3310:2013/03/22(金) 19:07:35.76
>>32
しつこいですね。。。
普通に考えて重要度が高い対策を先にプログラミングするよね?

「全く意味がありません。」って言ってたのに、「多少の効果はある」って意見変えましたね。
私と同意見になったので、もう言い争う必要は無くなったわけです。
34デフォルトの名無しさん:2013/03/22(金) 23:34:16.78
> 「全く意味がありません。」って言ってたのに、「多少の効果はある」って意見変えましたね。

いいえ。全く意味がありませんといった私は>>32ではありません。
35デフォルトの名無しさん:2013/03/23(土) 03:10:52.59
ふーん
36デフォルトの名無しさん:2013/03/23(土) 14:52:35.44
rubyでいいです
37デフォルトの名無しさん:2013/03/23(土) 21:29:58.44
Perl最強
38デフォルトの名無しさん:2013/03/24(日) 01:46:34.21
PHP=ゴミというニワカの先入観抜きにしても、現実問題Rails一つに全く叶わない
単に非プログラマでも使いやすいという以外にPHPの利点はない
39デフォルトの名無しさん:2013/03/24(日) 01:48:46.33
>>38
馬鹿かお前?

Rails(フレームワーク)と比べるならPHPのフレームワークだろ。
どうせ比べることが出来るぎらいの知識は持ってないだろうがなw
40デフォルトの名無しさん:2013/03/24(日) 01:48:48.59
じゃあなんでRubyの案件が全然増えねえんだよ
41デフォルトの名無しさん:2013/03/24(日) 01:51:18.54
>>39
んなもんわかってるつーの
PHPという言語自体が一つのフレームワークであるRails一つの全く叶わないほど貧弱ってことだよ
PHPのフレームワークはRailsの後追いで機能を真似ても、CSSやJSの開発環境、テンプレートエンジン、その他無数の拡張機能はPHPには絶対に導入できないだろ
42デフォルトの名無しさん:2013/03/24(日) 01:52:20.66
アカン 日本語がおかしくなったw
43デフォルトの名無しさん:2013/03/24(日) 01:58:47.81
>>40
非プログラマでも扱えるという点以外に全く理由が見当たらない
PHPで最も人気があるフレームワークの一つのCakePHPなんてRailsの完全弱体化版だしな
44デフォルトの名無しさん:2013/03/24(日) 02:09:47.19
>>41
> CSSやJSの開発環境、テンプレートエンジン、その他無数の拡張機能はPHPには絶対に導入できないだろ

絶対導入できないという意見に
技術的裏付けかなんかあるのか?

お前が出来ないといったことが
既に実現できていたら笑うなw
45デフォルトの名無しさん:2013/03/24(日) 02:15:22.27
>>44
お前本当に触ったことあるか?
PHPで開発してるときにSassやCompassを使おうとするとわざわざRubyのgemでコンパイルしてからブラウザに表示しなきゃならない
ウェブアプリの開発形態がgemによってどんどん置き換えられてることによって、PHPで開発してるのにRubyのコンパイルが必要というアホらしいことになってるんだが

さらに言えばテンプレートエンジンなどはRubyでないと組み込めなくて、PHPで手間をかけても恩恵を受けられるのは一部しかない
46デフォルトの名無しさん:2013/03/24(日) 02:17:55.43
>>45
SassはCompassはこれらのプログラムがRubyで書かれてるからってだけだろ
別にRubyを使うわけじゃない。CLIプログラムとして使うだけだ。

お前のその理屈で言えば、Rubyで開発しているのにC言語が必要ってことになるな。
C言語で作られた何か(Linux)を使ってるだろ。
47デフォルトの名無しさん:2013/03/24(日) 02:22:17.95
>>46
Rubyで開発してる時にC言語が必要となる場面なんてない
逆にPHPで開発してるとgemの常駐監視が必要なんて明らかに不要な手間じゃないか

枚挙に暇がないが、例えば認証機能を組み込むときにもPHPフレームワークでは仕様が一通りしかないがgemなら選択肢はいくらでもあるし拡張が効く
HamlやSlimのようなテンプレートエンジンもフレームワークに依存しないから、HTMLの記述一つとっても明らかにRubyに分がある
逆にPHPのメリットってなにかあるのか?
48デフォルトの名無しさん:2013/03/24(日) 02:23:15.36
>>47
Sass、Compassを使うときにRubyは必要ない。
Rubyが使えないデザイナーでも使ってるんだから。
49デフォルトの名無しさん:2013/03/24(日) 02:25:30.76
認証機能の仕様が一つしかない? 何言ってるんだ?
HamlやSlimだってPHPで使えるし。。
PHP用のテンプレートエンジン(PHP言語ではない)があるの知らないのか?

どんどん初心者臭いがしてきたな。
技術的に可能か不可能かの判断も出来んだろ?
50デフォルトの名無しさん:2013/03/24(日) 02:35:46.38
>>49
フレームワークに備え付けの認証機能しか組み込まれてないだろ それともPEARかどっかからダウンロードするのか?
PHP用のテンプレートエンジンっていわれてなんのことか調べたらSmartyがほとんどだったが、具体的にどんなのものがあるんだ?

CompassやSassを利用するにもバージョン管理してインストールして、常駐監視してと明らかに不要な手間なわけだが
たまたまそれがコンパイルを通じて利用可能というだけで、明らかに技術的に不可能なものがほとんどな件w
51デフォルトの名無しさん:2013/03/24(日) 02:37:24.54
> フレームワークに備え付けの認証機能しか組み込まれてないだろ 

PHPに備え付けではなく、フレームワークに備え付け?
違うフレームワークなら、違う認証方法になるということ?

フレームワークごとに認証方法が違うということが可能なら
そのフレームワークには、認証方法を変える方法があることぐらい
すぐに思いつくよな?

初心者臭初心者臭初心者臭
52デフォルトの名無しさん:2013/03/24(日) 02:38:15.93
> PHP用のテンプレートエンジンっていわれてなんのことか調べたらSmartyがほとんどだったが

今調べたのか、やっぱり一つも知らないで、「HTMLの記述一つとっても明らかにRubyに分がある 」と
言ったんだな。

初心者臭♪ 初心者臭♪ 初心者臭 ♪
53デフォルトの名無しさん:2013/03/24(日) 02:38:58.64
> CompassやSassを利用するにもバージョン管理してインストールして、常駐監視してと明らかに不要な手間なわけだが

Rubyは不要な手間多そうですね♪
54デフォルトの名無しさん:2013/03/24(日) 02:42:27.35
>>53
>やっぱり一つも知らないで、「HTMLの記述一つとっても明らかにRubyに分がある 」

Smartyなんて知ってて当然でほとんどメリットのないテンプレートエンジンが筆頭に挙げられるほど候補がないのか、って意味で言ったんだが…
どんだけ拡張性低いんだよw

>>53
やっぱり君、Rubyやったことないんだね
Rubyだと勝手にコンパイルして本番環境では圧縮してくれるんだ、PHPと違ってねw
55デフォルトの名無しさん:2013/03/24(日) 02:44:06.06
>>50
> PHP用のテンプレートエンジンっていわれてなんのことか調べたらSmartyがほとんどだったが



>>54
> Smartyなんて知ってて当然でほとんど

  ク    ク   || プ  / ク   ク  || プ  /
  ス  ク ス _  | | │ //. ス ク ス _ | | │ //
  / ス   ─  | | ッ // /  ス   ─ | | ッ //
  / _____  // /          //
.  /   l⌒l l⌒l \  ))   ____
. / / ̄| ,=| |=、| ̄ヾ   / ____ヽ
/ ̄/ ̄.  ー'●ー'  ̄l ̄ |  | /, −、, -、l  ))
| ̄l ̄ ̄  __ |.    ̄l ̄.| _| -| ,=|=、 ||
|. ̄| ̄ ̄  `Y⌒l__ ̄ノ ̄ (6.   ー っ-´、}
ヽ  ヽ    人_(  ヾ    ヽ    `Y⌒l_ノ
  >〓〓〓〓〓〓-イ   /ヽ  人_(  ヽ
/   /  Θ  ヽ|  /    ̄ ̄ ̄ ヽ-イ
56デフォルトの名無しさん:2013/03/24(日) 02:45:45.71
>>50
お前の大好きなHamlの
http://en.wikipedia.org/wiki/Haml には
↓って書いてあるぞw

Implementations

The official implementation of Haml has been built for Ruby with plugins for Ruby on Rails and Merb, but the Ruby implementation also functions independently.
There are also implementations in other languages:
HamlPy (Python)
LuaHaml (Lua)
MonoRail NHaml (ASP.NET)
NHaml (.NET)
Fammel (PHP)
HAML-TO-PHP (PHP5)
pHAML (PHP)
phamlp (PHP)
phpHaml (PHP5)
haml-js (JavaScript)
Text::Haml (Perl)
Scalate (Scala)
JHaml (Java)
Hart (Dart)
57デフォルトの名無しさん:2013/03/24(日) 02:46:35.51
>>55
>Smartyがほとんどだったが、具体的にどんなのものがあるんだ?

Smartyなんて知ってて当然で、君がPHPには素晴らしいテンプレートがあるっていうからもちろんそれはSmartyじゃないよな、という意味なんだけど…
PHPerって代案も出せずに代案も出せないで揚げ足取ることしかできないってよくわかったよw
58デフォルトの名無しさん:2013/03/24(日) 02:46:57.30
>>54
> Rubyだと勝手にコンパイルして

sass --watch css/style.scss:css/style.css

お前フレームワークに頼りっきりで
ここのコマンドが持ってる機能を知らんだろう?
59デフォルトの名無しさん:2013/03/24(日) 02:47:28.72
>>57
だが調べてSmartyしか見つけられなかったんだろう?w
60デフォルトの名無しさん:2013/03/24(日) 02:49:10.30
This is a port of Sprockets (Rails Asset Pipeline) for PHP.
https://github.com/Nami-Doc/Sprockets-PHP

Asset Pipelineって知ってるか?
61デフォルトの名無しさん:2013/03/24(日) 02:49:35.64
>>58
あのさ、そんなのわかりきってるんだけどw
そもそもなんでPHPで開発してるのにターミナル立ちあげてgemで監視しなきゃならんの、っていう意味ですがな
62デフォルトの名無しさん:2013/03/24(日) 02:52:17.76
>>60
んなもん知ってる、ってかマイグレーションをcakephpに持ち込んでよりRailsっぽくとかやってる流れは全て知ってる(最近のフレームワークにマイグレーションがあるのも知ってる)
それもRailsとgemの後追いで組み込みの容易性やGemfileでのbundle installの流れに比べると明らかに劣化コピー
63デフォルトの名無しさん:2013/03/24(日) 02:52:52.61
>>61
はい?

PHPでの開発を楽にするためでしょう?

俺は開発のためにいろんなツール(CLI or GUI or Web)を利用し、
それらのツールが何の言語を使って作られていようが何の問題なく使えますが、
お前はフレームワークに全部やってもらわないと何も出来ない人ですか?
64デフォルトの名無しさん:2013/03/24(日) 02:54:57.04
>>47より
> PHPのフレームワークはRailsの後追いで機能を真似ても、CSSやJSの開発環境、テンプレートエンジン、その他無数の拡張機能はPHPには絶対に導入できないだろ
その他無数の拡張機能はPHPには絶対に導入できないだろ
その他無数の拡張機能はPHPには絶対に導入できないだろ
その他無数の拡張機能はPHPには絶対に導入できないだろ
その他無数の拡張機能はPHPには絶対に導入できないだろ


>>62
> んなもん知ってる

  ク    ク   || プ  / ク   ク  || プ  /
  ス  ク ス _  | | │ //. ス ク ス _ | | │ //
  / ス   ─  | | ッ // /  ス   ─ | | ッ //
  / _____  // /          //
.  /   l⌒l l⌒l \  ))   ____
. / / ̄| ,=| |=、| ̄ヾ   / ____ヽ
/ ̄/ ̄.  ー'●ー'  ̄l ̄ |  | /, −、, -、l  ))
| ̄l ̄ ̄  __ |.    ̄l ̄.| _| -| ,=|=、 ||
|. ̄| ̄ ̄  `Y⌒l__ ̄ノ ̄ (6.   ー っ-´、}
ヽ  ヽ    人_(  ヾ    ヽ    `Y⌒l_ノ
  >〓〓〓〓〓〓-イ   /ヽ  人_(  ヽ
/   /  Θ  ヽ|  /    ̄ ̄ ̄ ヽ-イ
65デフォルトの名無しさん:2013/03/24(日) 02:56:15.49
>>63
本来PHPに範疇でないことをあれこれ後追いで詰め込んでいて、それらの機能を使いこなそうとするとかなりの障壁になる
さらにいえば個人の努力で頑張って持ち込んでも言語本来の組み込み性や拡張性そのものに関してPHPが優っているわけではないし、開発速度も落ちる
66デフォルトの名無しさん:2013/03/24(日) 02:57:44.91
>>65
開発速度で問題になってるのは
お前の技術力の無さの方だよw
67デフォルトの名無しさん:2013/03/24(日) 02:59:05.88
PHP使いがしつこいし、まあPHPで絶対に導入できないというのは言いすぎたわw
言い直すと導入できるものもあるが、できないものもあって、組み込み性や拡張性において煩雑になるのでRubyで開発した方が自然で生産性が高い
68デフォルトの名無しさん:2013/03/24(日) 03:00:40.85
>>66
PHPerは個人攻撃しかできないクズなのか?
ここまで譲歩してやってもなおPHPがRubyの後追いでしかなくて不自然な組み込みであることを露呈しただけだろ
69デフォルトの名無しさん:2013/03/24(日) 03:01:50.12
だが、ツールの生産性がかくても、それを使う人次第。

技術的に可能か不可能かもわからない。
技術的に可能なら、すでにあるはずと考えられない。
調べもしない。

そして他人が見つけてきたら言い訳がましく「そんなの知ってる」

こんなヤツは何を使っても生産性は低い。

よく言われてることだ。
問題を技術のせいにするな。できないのはお前が悪い。
70デフォルトの名無しさん:2013/03/24(日) 03:03:27.28
>>69
言語の特性の話をしてるのに個人攻撃しかできないのは残念
せめてPHPが勝ってる点一つでも挙げるべきだった
71デフォルトの名無しさん:2013/03/24(日) 03:03:44.14
>>68
お前が出来ないと思っていたことが
出来るとわかっても、なお認められないのですか?w

技術もない。謝ることも出来ない。
個人攻撃じゃない。叱られているんだよ。
72デフォルトの名無しさん:2013/03/24(日) 03:05:21.40
>>70
PHPが勝っている点。

wikipediaで使われてるのはPHP
大規模サイトを支えてる。
73デフォルトの名無しさん:2013/03/24(日) 03:08:29.31
所詮お前はRubyを盲信しているだけなんだよ。

全部やってくれるrails凄いって言ってるだけ。
じゃあ自分は?

お前は技術者じゃない。
ただの評論家でしか無い。
74デフォルトの名無しさん:2013/03/24(日) 03:08:55.45
>>72
PHPはスケールが効かなくてトラフィックが増えるとパフォーマンスの落ち込みが激しいんだけど…
むしろPHPは中小規模でトラフィックが問題にならない程度において速度面のメリットがある
75デフォルトの名無しさん
そこでASP.net