[PHP-users MLヲチ5]何とか、自力更生できました。
■ このスレッドは過去ログ倉庫に格納されています
00011
04/07/20 20:18ID:???ますます１日あたりの受信数が増え続けています。
もはや役に立つ情報満載間違いなしです。
PHP-users mailing list
http://ns1.php.gr.jp/mailman/listinfo/php-users
[PHP-users ML ヲチ4]二度目の投稿なのですが…
http://pc5.2ch.net/test/read.cgi/php/1085576406/
[PHP-users ML ヲチ3] Re:MLってなんですか？
http://pc5.2ch.net/test/read.cgi/php/1078749366/
[PHP-users ML ヲチ2] Re:MLってなんですか？
http://pc2.2ch.net/test/read.cgi/php/1066903820/
PHP-users ML ヲチ
http://pc2.2ch.net/php/kako/1031/10317/1031734100.html
0216nobodyさん
04/07/31 23:24ID:WRy9c9NNなるほど。
ところで....
php書いてる皆さんは、ローカルにテスト用のサーバー(LinuxでもWinでも)って、持ってるよね？
0218nobodyさん
04/08/01 02:59ID:???0219nobodyさん
04/08/01 05:17ID:???アフォなのは PHP ではなく PHP を使う人間の方。
何使っても同じ。
それか、コストかけてもその辺をカバー出来る Java を使ってなさいって事になる。
0220nobodyさん
04/08/01 06:28ID:???そうでなく、PHPをマイナーアップデート程度でも更新したら既存スクリプトの
一部が動かなくなる場合があるでしょ。
PerlやJavaに比べても挙動の変わる頻度が高すぎる。上位互換くらいまともに取ってくれと言いたい。
これじゃ客先に保守を任せることができないだろ。
メンテ契約で別途金を取れるんならともかく、いつまでもこっちでメンテやれる顧客ばかりではない。
あと、PHPはPerl辺りに比べて本体内蔵の関数で機能をカバーしすぎてて
いくらプログラミングでカバーしても本体側にセキュリティ的な穴が出やすい。
これもPHP本体を頻繁に更新する羽目になる原因の１つになってる。
0221nobodyさん
04/08/01 07:19ID:???自分はそんな状態に遭ったことは無いけど、言いたいことはわかります。
開発陣もそれを認識しているからext以下のモジュールを
本体組み込みからPECLに移行させる動きがあるんじゃないかと思う。
FreeBSDのPortsでも各モジュールをDSOとして追加するようになったし。
でもPHPをアップデートする前にChangeLogを読んで、
それが運用中のシステムに影響があるかを問い合わせられるぐらいの客じゃないと
保守を任せられないような気も。（予算とかはおいといて）
0222nobodyさん
04/08/01 09:06ID:5SNTpMWy提供しているサーバーのphpのバージョンを3から4に上げたらしい。
自称SEいわく、「バージョン4のほうが安定しているから」
おかげで、それまで動いていたスクリプトが一斉に動かなくなって、２徹したそうだ。
0223nobodyさん
04/08/01 09:18ID:???0224sage
04/08/01 09:28ID:0BVqyGanﾉｰﾊﾟｿに入れればどこでも開発できちゃうよん
0225nobodyさん
04/08/01 12:28ID:???普通アップデートする場合、テスト機で影響調べてからにしないか？
いきなり本番機をアップデートするとは、相当なキワモノだなその自称SE。
0227nobodyさん
04/08/01 14:08ID:???4/5 じゃなく 3/4 ならそういう方法もアリだったろうと思うが
0228nobodyさん
04/08/01 15:42ID:???よく聞く話だけど、あんまり実感無いな。
漏れが PHP に手を付けたのが 4.2 以降からで大幅な変更に会ってないからかも知れないが。
それでももう 3 年目だしなぁ。
案外、無茶な書き方をしているか、4.2 系辺りであった register_globals のデフォルト値変更辺りから
イメージ先行な話になってるんじゃぁ、とか思う時がある。
>>221
同意だけど、PECL って PEAR のせいで管理の緩いイメージがあってしソレこそ互換性が怖かったりする。
0229nobodyさん
04/08/01 16:37ID:???そういう上位互換取れてない仕様変更って，最近の fgetcsv() 以外だと何があったっけ？
「頻度が高すぎる」とか「まともに互換取れてない」とかいえる程の変更があったら，
自分の 4.0.6 の頃に書いたスクリプトもどっかで不具合起こしてそうな気がするのだが，
特にそういう問題が起きてないから逆に不安だわ(w
0230nobodyさん
04/08/01 18:17ID:???PostgreSQLの関数
session_register
とか。
よく使っていたけど、ことごとく変更されてコード書き直した方が
はやかった。
0231nobodyさん
04/08/01 18:22ID:???イメージ先行じゃないよ。
自分が体験したのだけでも、nl2brが吐くタグが<br>から<br/>になって、携帯とか一部ブラウザでちゃんと見れなくなった。
contentTypeヘッダー吐くと日本語エンコーディングできなくなったり
で、その対応がされたアップデートは、そもそも日本語処理に不備があったり。
あとは、FreeTypeがどうのこうの、とか、マイナーバージョンアップのたびになにか聞く。
なんかのセキュリティー対応のバージョンで、PostgreSQLと一緒に使えないバージョンもあったね。
PECLとかPEARとかでライブラリが発散してしまうと、さらにだめになるだろ。
PHP5にほとんど対応してないような現状をみても。
信用できないね。
0232nobodyさん
04/08/01 18:25ID:???いまさらなに？って感じだな。
MSXが16ビットになってよろこんでる感じ。
0233nobodyさん
04/08/01 18:34ID:???PostgreSQLが使えないのは4.0.6だった。
4.2.2でContent-typeを指定するとエンコーディングしなくなった
4.2.3でそこは修正されたけど、日本語処理にバグがある。で、これが4.2系列最終バージョン。
4.2.1以前はセキュリティーホールがあるから使うべきではない。
ってことで、4.2系列は全く使えない
4.3.0はオブジェクトの=演算子の扱いがかわってる。
で、4.3.2でprintf系にバグ。テストしてないことがバレバレ。
エンバグ多すぎ。
0234nobodyさん
04/08/01 18:59ID:???<br/> じゃなくて <br /> ね．
これで見れなくなるブラウザの実装の方に問題があるが，
まぁ商用サイト作ってるとそうも言ってられないか．
>>232
意味わからん．
0236nobodyさん
04/08/01 20:30ID:???あぁそういうことか．
まぁ「PHP はオブジェクト指向言語ではない」とマニュアルで言い切ってるくらいだし，
生まれが OOP じゃない言語の OOP 機能って，
「非 OOP なコードも書ける」ってのが重要だと思うんで，最低限以上のものにはなりにくいと思う．
もっとガチな OOP したい人はそういう言語を使え，ってことで．
// あと MSX TurboR は Win95 より 5年ほども前なので，
// MSX の例えは適切ではないと思われ．いらん揚げ足取りですが(w
0237nobodyさん
04/08/01 21:04ID:???世の中すでに386が当たり前で、X68000もX68030で32ビット化したころに、16ビット化、それもバス幅は8ビットの半16ビットで、みたいな感じだった気がする
オブジェクト指向はどうでもいいんだけど、フレームワークとか再利用が声高に叫ばれるなかで、いまだに枠組みの提案がない。
フレームワークとか再利用のためにはオブジェクト指向が便利なんだけど。
なんか、明確な目的なく、とりあえずオブジェクト指向にしましたよ、という印象をうけまくり。
0238nobodyさん
04/08/01 21:20ID:???うーん、でもその中途半端なOOPを中途半端に見た目だけまともにするために
実行速度が落ちてたら本末転倒って気がするんだけどなー。
元々、DSOでの起動速度はともかく処理速度ではPerlに負けてたんだし、
さらに遅くしてどーすんの？とか思った。
0239nobodyさん
04/08/01 21:22ID:???まともな上位互換は無いしねｗ
0240nobodyさん
04/08/01 22:13ID:???PostgreSQLとかJavaとか、開発環境に関してはなにも気にせず最新バージョンインストールしたりするけど、PHPはインストールする気にならん。
3桁目のバージョンが変わっただけでも。
0241nobodyさん
04/08/01 22:51ID:???開発してる側がプログラム言語作ってるって意識に欠けてるんじゃないかな。
なんだかその辺のアプリのマクロ言語みたいな機能拡張の仕方してると思う。
0242nobodyさん
04/08/01 22:53ID:???バージョン間完全互換かつエンバグしない開発体制の言語を誰か作ってくれ．
良さそうなら PHP から乗り換えるからさ．
0243nobodyさん
04/08/01 23:00ID:5SNTpMWyキワモノもきわめつけキワモノらしい。
「FireWallなんていらない。サーバーのセキュリティをちゃんとしてれば問題ない。」
なんてことも言ってるらしい。
ついでに...php.iniを知らなかったらしいし（禿藁
>>226
php3は、自称SE氏が削除したらしい。
で、それまで動いてたプログラムを書いたヤツは辞めてしまってたらしいから。
となれば、３→４にした自称SEが如何にDQNかがようわかる。
0244nobodyさん
04/08/01 23:34ID:???完璧じゃなきゃ乗り換えんてか？じゃあ一生PHP使い続けることに
なりそうだな。ご愁傷様。
「PHPよりマシ」レベルで良いならperlなんてのもあるけどね。
0246nobodyさん
04/08/02 00:18ID:???// 「完璧じゃなきゃ」んなこたどこにも書いてねー，ってのはまぁおいといて……
つまり全ての点で完璧なプログラム言語なんて一生出てこねーってことは理解してんでしょ？
色々な言語がそれぞれ別々にダメな点があって，
それを我慢できる人がそれを使う，って現実も理解してんでしょ？
だったら PHP のそういう点はバージョン間非互換にある，とか思って，
その上で PHP 使うなり別の言語使うなりすればいいじゃん．
242みたいな完璧な言語を欲しがってるのは，ここで PHP に文句たれてる連中の方なんだと思うよ．
ところで Perl はバージョン間互換はかなりのものだと思うが OOP って点ではどうかなぁ……
0247nobodyさん
04/08/02 00:36ID:???> なんか、明確な目的なく、とりあえずオブジェクト指向にしましたよ、という印象をうけまくり。
> 開発してる側がプログラム言語作ってるって意識に欠けてるんじゃないかな。
> なんだかその辺のアプリのマクロ言語みたいな機能拡張の仕方してると思う。
この意見を見て思ったこと。
これがインタプリタパターンって奴だな。
0249nobodyさん
04/08/02 07:03ID:???Ruby？
自称言語オタクというだけあって、いい言語だし、へんなエンバグはなさげ。
ただし、たくさんたくさんの機能はいまのところなさげ。
0250nobodyさん
04/08/02 13:54ID:???動くサーバ少ないんじゃないか？
0251nobodyさん
04/08/02 13:59ID:???それにPHP5が動くサーバーの数よりは多い(￣ー￣)
0255nobodyさん
04/08/02 14:13ID:???0256nobodyさん
04/08/02 14:16ID:???このスレの住人の大半はレンタルでは未対応だった頃からPHPに着目してて
PHPは自前サーバーで運用するのが当然と思ってる人ばかりだと思ってたけど。
レンタルのなんてオプションもいじりにくいしアップデートもできないしで使いにくいと思うけど。
0257nobodyさん
04/08/02 14:20ID:???PHP5が使えるサーバーは増えないと思ったわけで。
ところで
22896
単純なロジックの問題で、環境にはあまり左右されない問題なのに、なにを偉そうにしてるですか？
しかも、解決策として呈示したものも、どう「いけるでしょう」なのかわからないのですが、なぜこんなに得意げですか？
0258nobodyさん
04/08/02 14:21ID:???0259nobodyさん
04/08/02 14:27ID:???0260nobodyさん
04/08/02 14:34ID:???普通の仕事でもレンタルサーバは選択肢に入れて作っておかないと使いまわしが効かん。
下位互換がしっかりしてるか、移行ツールでも出してくれりゃ問題ないのにな。
0261nobodyさん
04/08/02 14:44ID:???関数の下位互換はPEARのPHP_Compatである程度カバーできるかと。
ヲチスレで他のPHP関連スレよりPHPの話をしているというのも奇妙な気分ですな。
0262nobodyさん
04/08/02 14:57ID:???こっちの方が楽しいし。
PEARのナントカで大丈夫、っていう言葉が一番あてにならない気がス
0263nobodyさん
04/08/02 15:32ID:???ﾎﾟｶｰﾝ
0264nobodyさん
04/08/02 15:52ID:???窓の手で設定してるか、IEが古い+例のチェックボックスがオンというオチに１票。
0265nobodyさん
04/08/02 16:07ID:???0267nobodyさん
04/08/02 16:45ID:???別の画面で別のアカウントでログインしたい、と。
単純にセッションを使うと、画面ごとの認証管理ができない、と。
同時に別のアカウントでログインしたい、という状況が、権限管理をちゃんとできてない場合以外に思いつかない。
0269266
04/08/02 17:20ID:???どうもありが㌧。
１つのページで１ユーザーしか権限与えられてない。与えられないとかそういうことか？
だとしたらトリッキーなことしないでまっとうに直したほうがマシかと
>>268
ﾜﾛﾀｗ
0270nobodyさん
04/08/02 17:42ID:???例えば「営業」と「販売」っていうアカウントがあって、「営業」でログインして作業中に「販売」の作業も必要になって、別の画面を開いて「販売」でログイン。
単純なセッション管理だと、「営業」側が使えなくなってしまう。
という問題を解決したいんだと思われ。
0271nobodyさん
04/08/02 17:43ID:gm6NGv/f自分で売りを立てて、自分で出荷したように見せかけて...不正経理の温床だ！
0272nobodyさん
04/08/02 17:58ID:???LiveUserとか。
0273nobodyさん
04/08/02 18:27ID:???0275nobodyさん
04/08/02 18:51ID:???0276nobodyさん
04/08/02 21:55ID:???いままでは一人のユーザーに一つのロールの割り当てで
ページにはロールを複数許可ってやってたんだけど
ページには一つのロールの許可で１ユーザーに複数の
ロール割り当てのほうがいいのかなぁ。。。とちょっと疑問
0277nobodyさん
04/08/02 22:43ID:???Jakarta Turbineの権限モデルを参考に作ってるが、
http://jakarta.apache.org/turbine/
http://jakarta.apache.org/turbine/fsd.html
* ユーザ
(* グループ)
* ロール
* パーミッション
をベースに構築するのはなかなか良い感じ。
* "Edit Users"のようなパーミッションを作成する。これはアクション(ペー
ジ)あるいはより細かい単位に割り当てる。例えばユーザ情報を編集するア
クションのサブアクション"パスワード変更"を実行するには"Edit Password"
権限が必要というようにする。
* "Admin", "User", "Guest"のようなロールを作成する。ロールにふさわし
いパーミッションを複数割り当てる。
* ユーザにはロールを割り当てる。必要であれば複数のロールを割り当てる。
パーミッションは割り当てられたロール中どれかにあれば良い。
のような感じ。説明が難しいが。
0278277
04/08/02 22:46ID:???結果としてページ(アクション)には一つ(あるいは複数)のパーミッションを
割り当てることになる。実行の承認はユーザが必要なパーミッションを保持
しているかどうかで決定する。
わかりにくかったらスマソ。
0279nobodyさん
04/08/02 23:00ID:???横断的関心事を織り込む仕組みが全くないWeb処理系って、めんどくさくてやってられん。
Javaだったらとりあえずコンテナに認証の仕組みがあるし、フィルターもあるし。
0280nobodyさん
04/08/02 23:15ID:???http://mojavi.org/
0281nobodyさん
04/08/02 23:35ID:???ヘタレの集まり
って理解でOK?
0283nobodyさん
04/08/03 00:19ID:???0285276
04/08/03 00:28ID:???おーサンクス
アクションとロールが1:nで
ユーザーとロールが1:nで
アクションに許可されてるロールをユーザーが持ってればＯＫってことね
0286nobodyさん
04/08/03 00:30ID:???前処理のフィルタは知らんけど
0287nobodyさん
04/08/03 00:36ID:???それを、それぞれのスクリプトが気にせずにできるかどうかが問題。
っていうか前処理が一番大事で。
もう、認証とかトランザクションとか、いちいち書くのはめんどくさい。
0288nobodyさん
04/08/03 01:40ID:???>どれをメンバ変数にするべきかどうかという問題は
>悩んでもなかなか答えがでないとおもいます。
明日から悩まずに生きていくことにします。
>はじめからスマートなクラス設計なんてできるはずがないし、
>そもそもセオリーなんてありません。
(設計)思想も捨てることにします。
0289nobodyさん
04/08/03 09:09ID:???俺、最近まで PHP 専門だったけど他の言語にも色々手出してみた。
PHP に持ち帰れるもの多いね。
0290276
04/08/03 11:57ID:???その通り。
自分でパーミッション取得とか、権限承認とかをスマートにやるのは面倒なの
でMojaviのようなフレームワークと組み合わせるといいよ。
0291nobodyさん
04/08/03 14:41ID:???ふと思ったんだが、どういう意図があるんだ？
0292nobodyさん
04/08/03 14:50ID:???ふと思ったんですが、
>session.cookie_lifetime = 0
のところを
session.cookie_lifetime = 600 ;（つまり10分）
にしたりしたら
セ ッ シ ョ ン が 切 れ る だ け で す 。
0294nobodyさん
04/08/03 15:12ID:???0297nobodyさん
04/08/03 17:27ID:???LiveUser だけでいいじゃん。
権限コントロールの話に限れば LiveUser のようなライブラリ導入するまでがコストの下がる部分、
その後は Mojavi 入れる分、AuthorizatioHandler/User との接合の手間が増えるだけでは。
おまえただ Mojavi って言いたいだけちゃうんかと小一時間・・
Mojavi の話したいだけだったら pear スレでやってるよ。
0299nobodyさん
04/08/03 19:02ID:???どこ？
0300nobodyさん
04/08/03 19:56ID:???Pearスレ
http://pc5.2ch.net/test/read.cgi/php/985665522/
0301nobodyさん
04/08/03 22:17ID:???なんでそんなにあおり口調なのだろうか。
メアドうんぬんも、つっこむ必要があるとは思えないし。
場を乱してるだけな気がする。
0302nobodyさん
04/08/03 22:32ID:???確かに、煽り口調だが、あれでは「ごめんなさい」の一言で終わってしまうではないか。
自身も釣りを楽しみ、同時に周囲にも攻防を楽しませる域には達していないな。
現状はガキが偉ぶっているようにしか見えん。
0303nobodyさん
04/08/03 22:41ID:???どんな呼び出し形態かが関わりそうなものでもない。
役立つ情報がまったくない単なる煽りというのもよくないな。
0304nobodyさん
04/08/03 22:42ID:???0305nobodyさん
04/08/03 22:51ID:???漏れもそう思う。
丸投げMLに誘導して、そっちで叩いたり、なでたり、伸ばしたりすりゃ良いのにね。
usersでやってたら、自分の発言もS/N比の悪化の一翼を担っているという意識はないのかね。
0306nobodyさん
04/08/03 23:25ID:???配列使うとJavaと連携できないっていってるだけで。
ところで、Java連携ってJ2SDK1.3までしか対応してないんじゃなかったっけ？
0307nobodyさん
04/08/03 23:59ID:???まぁ何かあるとしても 5 以降なんだろうけど。
0308nobodyさん
04/08/04 00:50ID:???0309nobodyさん
04/08/04 00:53ID:???俺もそう思う。マルチポスト以外は特に目くじら立てるほどのものじゃないだろ。
問題になるソースは示されてるんだし、「試しに動かしてみたが問題なく動く」とかいう
情報を示すんならともかく、今回のはむしろ爺の方がマナーに反した投稿をしてると思う。
情報不足とか言ってるが普通に考えれば初期質問としては十分な情報が出てるよ。
あれでJava連携でなく動いて当たり前のコードとかならただの丸投げなんだろうけどね。
爺は責任持って動作確認くらいはしてから返答しれ。
0310nobodyさん
04/08/04 01:15ID:???いいえ。MLの投稿をネタに「技術レベルの高い」感じを装って議論をするスレです。
また特に権威者、学者ぶる必要はありません。
0311nobodyさん
04/08/04 01:21ID:???http://www.freeml.com/ctrl/html/MessageListForm/[email protected]
0313nobodyさん
04/08/05 16:21ID:???0314nobodyさん
04/08/05 16:50ID:gqHW/Lypあーいうのが繰り返されて、MLがダメになっていくんだろうな。
もはや、ジイは牢名主のようだな。
usersはPHPユーザの牢獄になったのか?
■ このスレッドは過去ログ倉庫に格納されています