【PHP】下らねぇ質問はここに書き込みやがれ 14

2022/09/20(火) 16:46:23.39

!extend::vvvvv:1000:512
!extend::vvvvv:1000:512
★スレ立て時 ↑ が3行以上になるようコピペ

PHPに関する質問スレです

前スレ
【PHP】下らねぇ質問はここに書き込みやがれ 13
https://mevius.5ch.net/test/read.cgi/tech/1631147923/

次スレは>>980以降
VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured

VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured

2023/02/17(金) 01:00:09.42

メモ帳野郎が湧くぞ

2023/02/18(土) 16:21:45.50

cd ~/.ssh

の ~ ってどういう意味なのでしょうか？

cd .ssh だと確かにこのディレクトリに入れません。決まり文句と覚えておけばよいでしょうか？

2023/02/18(土) 17:00:32.72

>>505
スレチ

2023/02/25(土) 19:20:55.02

>>501
ホームディレクトリの略だよ

2023/02/26(日) 23:08:14.21

requireとextendsはどう違うの？
requireはclassだけ呼ぶのかと思ったらプロパティも呼ぶし混乱する
この2つ重なってない？

2023/02/27(月) 00:20:33.97

includeとrequireを混同するのは微笑ましいあるあるだけど
extendsは初めて見るパターンで困惑する

2023/02/27(月) 01:15:02.38

無能なんだな俺

でも分かった
requireは親のクラスを使ってインスタンスが作れる。だから呼び出し元でclass Hoge { しなくていい
requireは更に親のphpファイルで作った変数が使える
requireは更に親のphpファイルで作ったコンストラクタを使える
つまりclass内が使える

一方のextendsはclass Hoge { の外にあるメソッドとかを継承する

↑この理解はどうかな？

2023/02/27(月) 01:24:44.70

メソッドもclass Hoge {の中にあるのか。やっぱ被ってるように思うけど

2023/02/27(月) 04:20:55.93

requireはあくまでも外部のPHPファイルを読み込んでるだけ
そこに記載されたクラスを継承して新たにクラスを作ることとは何の関連もない
ポリモーフィズムの概念やらオブジェクト指向がなんたるかを勉強してきたほうがいい

2023/02/27(月) 04:22:36.00

ちなみにネコがワンと鳴くみたいな説明してるとこは見ない方がいい

2023/02/27(月) 04:37:15.50

俺はPHPだけじゃなくて、Windowsアプリ開発もできる

2023/02/27(月) 08:40:23.44

>>512
You Tubeいくつか見てみるよ

2023/02/27(月) 13:52:10.05

初心者なんだけど他人のコード見てたら

if(true){
・・・
}

if(false){
・・・
}

とかあるんだが、これはどういう条件式なの？
ifの中に変数名が入っていたりしたら入ってるかどうかぐらいなのはわかるんだけど、
不思議な書き方なのでよくわからんです

2023/02/27(月) 13:59:57.21

>>516
・もともとはif文の中に条件判定が入ってたが、削除したときに横着した
・実験でコメントアウトしたり戻したりを頻繁にしてたときのなごり雪
ふざけすぎたコーディングの跡で

2023/02/28(火) 01:30:55.97

やっぱrequireよく分からんな
とあるwebページ作ってて、管理しやすくするためにphpファイルをiedex.php、data.php、hoge.php、hogehoge.phpみたいに分ける
data.phpにインスタンスまとめる。この場合data.phpは各クラスをrequireする
index.phpはHTMLとして表示される。この場合ここはdata.phpをrequireする
hoge.phpとhogehoge.phpはclassだけど、他のクラスから継承しないならrequireしたりしない

extendsは分かったかも
とあるクラスからインスタンスを作る。このインスタンスをタイプは同じだけど性質によって分けたいならextendsする
例
アニマルクラスを作る。プロパティは
種族
年齢
吠える
そのクラスから犬クラスと猫クラスに分けてからインスタンス作りたい場合、extendsでアニマルクラスを継承する（プロパティは共通だから）

これでどうかな。requireせずにextendsだけする事あるのだろうか？必ずrequireやincludeとかのファイル読み込みをセットで使う？
それと皆は本当にハッキリとrequireするかしないか分かるの？

2023/02/28(火) 01:34:20.21

それと、クラスメソッドやクラスプロパティ使う時も皆は明白に判断つくの？
インスタンス作成回数とかid作成はクラスメソッドとかみたいのは分かるけど俺はハッキリと判断つかないな

2023/02/28(火) 01:50:28.85

HTMLに変換されるindex.php上で他のphpファイル上で定義されたメソッドを実行する場合、requireしなくてもいいのはなぜ？
requireはインスタンス作成時にのみ行うのかと思わせて他のケースもあるみたいで分からなくなる

2023/02/28(火) 02:32:15.26

requireで読み込むファイルはクラスや関数が書かれたライブラリだったり
定数や共通の設定事項を記載したファイルだったり
単にhtmlを出力してるだけのファイルならその内容が読み込んだ側で出力されるし用途は様々
C言語で書かれたPHPコアライブラリに含まれてる関数群やPDOなんかのクラスは
使用するにあたってrequireなんて書いたりしないけど
PHPで作られてるものはrequireしないと使えない
インスタンスだの継承だのそんな次元の話じゃない

2023/02/28(火) 07:09:43.47

基礎的なところからすれ違ってんだから体系的に学習できる本でも読めよ
phpは基礎が学べればあとはマニュアルでなんとかなるくらいマニュアルが優秀だけど、そもそもの基礎がズレてたらマニュアルも読めん

2023/02/28(火) 08:28:11.46

基礎がおかしいか。Progateで勉強したけどrequireするしないの差が曖昧だった
何で勉強しようと思ったかというと、今使ってるブログサービスで不具合あって、そこがWordPressだから直せないかなと思った
である程度勉強してブログ設定見たらユーザーが触れる部分はHTMLで勉強の意味無かった
意味無かったけど途中までやったから全部終わらせた
PHPかなり難しかったよ。でもCやってたら楽々なんだろうな

2023/02/28(火) 09:06:04.41

WordPressはphpとはまた別物
多分、両方エキスパートって人はいないと思う

そもそも一般的なphp開発だと、requireとかほぼ使わなくなってる
composerのautoloadがメジャーだよ

WordPressがやりたいんだったら、一般的なphpじゃなくてそれ用の本読んだほうがいいかなぁ

2023/02/28(火) 09:19:48.98

>>518
まず言語仕様として1ファイル１クラスじゃなくてもいい。1ファイルに複数クラス定義を書いてもいい。
（ただし作法としては1ファイル1クラスにするのが望ましい）

そしてrequireは別のファイルからコードを挿入してくるだけの機能
例えばecho文が書かれたPHPファイルをrequireしたらその時に実行される。

2023/02/28(火) 12:09:34.54

ファイルには関数やクラスの定義だけしておくパターンが多いかな

2023/02/28(火) 16:54:00.06

そんなに違いが気になるなら、Ruby の逆引き本を読んだ方が早い

Ruby on Rails が良い

2023/02/28(火) 18:14:11.17

Rubyって読みづらくね？
波括弧ないしif～endとかダサい

2023/03/01(水) 01:33:59.12

>>528
そういうのをかっこいいと思ってる人たちが使っているんです

2023/03/01(水) 03:49:41.82

file_put_contentsでjsonにデータを書き込みたいんだけど、jsonに
[ ]
を予め用意しておいてその中にデータ書き込むって出来ないかなあ？

2023/03/01(水) 08:43:06.85

>>530
オブジェクトに[ ]を用意してその中にデータを書き込んで
最後にjsonにしてfile_put_contentsで書き込むと良いよ

2023/03/01(水) 10:36:45.89

>>531
データ入れる場所指定できるんですね
試してみます！

2023/03/01(水) 10:37:24.79

ちがうか、先に違うオブジェクトにしておくのか

2023/03/01(水) 11:19:20.74

何で出来ない奴はこうも説明が下手なんだ・・・
何を言っているか分からんよｗ

2023/03/01(水) 17:28:10.18

>>530
動的に書き込みたい部分以外はJSONのテンプレートとして事前に用意しておきたいってことだろうか
そう仮定すると考えるのはこの3通りくらい

1) テンプレートを一度jsonオブジェクトとして読み込んで、目的の階層にデータを代入して、まとめて書き出す
2) テンプレート側にデータとして存在しえない文字列を用意しておいて、文字列として読み込んだjsonから文字列置換する
3) JSONを読み取る側を改修して、固定部分と動的部分を別ファイルから読み取るようにする

2023/03/01(水) 20:41:59.79

>>535
ああ、一旦オブジェクトなり配列にして、未登録のデータだった時にオブジェクト一個追加してJSON全部上書きしちゃうのは自分でもできそう

データの数も3桁行かない程度だし、データ読み出して書くのもそんな重くならないか

後は動的にデータおる部分の見直しですね

2023/03/05(日) 11:24:39.77

どちらが適正ですか？

try {
//ファイルを保存先ディレクトリに移動させる
if (move_uploaded_file($_FILES['upload_image']['tmp_name'], $save)) {
echo 'アップロード成功しました。';
} else {
echo 'アップロード失敗しました。';
}
} catch (Exception $e) {
echo 'アップロードエラー： ' . $e->getMessage();
}
try {
//ファイルを保存先ディレクトリに移動させる
move_uploaded_file($_FILES['upload_image']['tmp_name'], $save);
} catch (Exception $e) {
echo 'アップロードエラー： ' . $e->getMessage();
}

2023/03/05(日) 12:02:39.82

>>537
上

2023/03/05(日) 13:31:58.17

>>538ありがとうございます。

2023/03/05(日) 15:15:03.70

phpの実行を３つに区分したとして、
「データベースのmysqli接続」
「POST送信データバリデーションチェック」
「クエリ実行」
try-catch文、トランザクション処理を記述する場所
って以下であっていますか？

try{
//データベース接続処理
...
//入力バリデーションチェック
...

//トランザクション開始
$mysqli->begin_transaction();
//クエリ実行
...
// トランザクション処理
if (!$mysqli->commit()) {
throw new Exception("トランザクションが失敗しました。");
}
}catch (Exception $e) {
echo $e->getMessage();
$mysqli->rollback();
}

2023/03/05(日) 17:02:00.95

commit部分のthrowは要らないのでは？

2023/03/05(日) 17:44:49.95

commitしようとしたら、ファイルが壊れました、とか

2023/03/05(日) 18:28:19.70

DB壊れたらシステム止まって別のトランザクションも動かないだろうから
全てのトランザクションに書かなくて良いと思う

2023/03/05(日) 21:45:08.47

PDOで例外投げるよう設定して
catchすべきなのはPDOExceptionじゃね

2023/03/06(月) 10:18:27.62

こういうのもchatgptさんに
PHPでDB接続する例文書いて。例外おきたときの対処もよろ。
と言うだけでだいたい書いてくれる。

でもさ、
もしも全員がchatgptさんだけ使って
ブログ記事などが一切なくなった場合は
どこからサンプルソース解析してくるんだろう？
公式リファレンスしか存在しなくても
たくさんサンプルあみだせるんかな？

2023/03/06(月) 13:06:49.25

chatgptかなりいい加減だぞ
こっちが詳しく聞いてもありえないコードと解説もよくするし

2023/03/12(日) 10:28:41.64

PDOStatement::columnCountって
PDOStatement::fetchができる回数を示しているものであってますか？
int(0)を想定したクエリ出しても
どんなクエリでも常にint(n)になってしまってお手上げです
PDOStatement::rowCountはSQLiteのため常に0を返すとのことで使えません
ものすごい古いNAS上に構築された環境なのでそれの影響もあるかもしれませんが
ループ上でfetchがbool返すまでやるしかないでしょうか？

**547** (ﾜｯﾁｮｲ d6a7-Cjjx) · 2023/03/12(日) 10:29:40.64

どんなクエリでも常にint(n)になってしまってお手上げです
↓
どんなクエリでも常にint(n)になってしまってお手上げです (n>0)
です

2023/03/12(日) 10:33:06.48

> PDOStatement::fetchができる回数を示しているものであってますか？
間違ってます。

2023/03/12(日) 11:14:32.05

そうですねすみません
よく読んだら全然違った
久々にPHPいじってるのでこんなこともわからなくなってるとは・・・
*が最大数で1以上になるのは当たり前ですね

2023/04/24(月) 10:58:21.24

みなさんはIF地獄になったときどうしてますか？
最適化するまで試行錯誤しますか？
それとも「できる・動く」を優先して進めますか？

2023/04/24(月) 11:03:45.16

動けば良いってものじゃない

2023/04/24(月) 11:05:33.74

>>551
メソッドか関数にして追い出しておく
あとでリファクタする際にその関数だけでテストできるように下準備だけしておく

未来の自分・他人がやりやすいようにして今は目をつぶる、がコーディングの鉄則
最適化は最初の仕事かつ最後の仕事だが、途中でやるのだけはNG

2023/04/24(月) 16:04:38.35

>>553
メソッドに追い出してもIFが続きますね。
どちらにしろ「Aがある場合～Aがない場合～」みたいな処理が必要ですし。

綺麗なコードとわかりやすいコードって違うと思うんですよね。
1ファイルにダラーっとコードが記述されると汚いですが、
上から下まで読めば何がしたいかは大体わかります。

しかし、クラスなりメソッドなりに分けると、複数ファイルにまたがって複雑です。
適切な名前を付けてファイルを参照しやすくすれば手間は軽減されますが、
今度は適切な名前を考えるのに時間を消費し、開発に遅れが生じてしまいます。

2023/04/24(月) 19:55:07.81

綺麗でもわかりにくいコードはあるが、汚いのにわかりやすいコードというのは無いな

2023/04/25(火) 07:41:04.47

>>554
一度適当なフレームワークでシステム作ってみるといいよ
感想がぜんぜん変わるから

> 今度は適切な名前を考えるのに時間を消費し、開発に遅れが生じてしまいます。

copilotさんとか使うといい

2023/04/25(火) 08:12:37.51

>>556
一応、CakePHP→Laravelと通ってます。

単純なシステムなら綺麗でわかりやすいコードになりますが、
複雑な要件になると、力技の部分がどうしてもでてきます。

2023/04/25(火) 13:06:17.18

>>557
フレームワーク使用したことがあるのに「クラスなりメソッドなりに分けると、複数ファイルにまたがって複雑です。」とか言っちゃうのはかなりまずい気がするけど、複雑な要件の実装時に十分に責任分解できてないんじゃないかなぁ…

https://github.com/alexeymezenin/laravel-best-practices/blob/master/japanese.md#%E5%8D%98%E4%B8%80%E8%B2%AC%E4%BB%BB%E3%81%AE%E5%8E%9F%E5%89%87

これのGoodがGoodに感じられないってことだよね？

2023/04/25(火) 13:27:47.02

コミュニティーの議論や歴史を調べること

Ruby on Rails では、コントローラーの肥大化を防ぐために、
Skinny Controller, Fat Model を推奨した。
その結果、モデルが肥大化した

そこで今度は、モデルの処理を減らすために、
Form Object, Service Object へ処理を分けた

また表示処理は、Presenter へ分けた。
それで、Form Presenter, Model Presenter が出来た

2023/04/25(火) 13:27:53.51

こういうのは2つ実際に書いてみて、両者を見比べて良い方を採用する
理屈よりも、自分の目で見て判断するのが良い

2023/04/25(火) 15:25:51.23

>>558
いえ、これはGoodです。理想です。
しかし、システムの規模が大きくなると処理が増えるんです。
複数のメソッドを役割ごとに用意し、コントローラから指示を与えなければいけません。

>>560
今の自分はそうしてますね。
PHPに限らず、Javascriptなんかも最初はそのまま書いて、
後からjQueryにしたり、Vueに変更したりします。

結果、倍時間がかかって効率が悪くなります。
同じことをしているとモチベが下がり、開発意欲は失われます。

2023/04/25(火) 15:27:54.01

古いPHPのシステムを保守するならDockerにぶち込むのが一番？

2023/04/26(水) 13:32:18.14

結局ifは減らないんだよね
ファイルを分けても分けなくても、オブジェクト指向でもそうでなくとも

Strategy/StateパターンとTemplateパターンの併用にして
スイッチっぽく分岐をわかりやすするのが一番かな

2023/04/26(水) 13:45:21.48

ifを無理に減らす必要は無いのでは？
必要なら書かなきゃいけないし
ただ処理が集約出来るとかなら外に追い出したらいいし
パターンが多い場合はswitch()の方が良い場合も確かにあるし
ケースバイケースかと

elseifが並ぶのは個人的に嫌いだがｗ

2023/04/26(水) 13:47:42.93

elseif嫌いわかる
elseの中にif書きたい

パターン3つ以上になるならswitchにするな

2023/04/26(水) 13:57:33.29

else if は嫌いというか、あとで取捨選択が面倒なので
if文単独で成り立つようにしておくことが多いな

2023/04/28(金) 14:22:47.60

訊きたいことありましたが自決しました

2023/04/28(金) 14:52:55.46

おお死んでしまうとはなにごとだ

2023/04/28(金) 15:31:57.97

盆には帰ってこいよ

2023/04/30(日) 00:40:31.69

PHP7.2.24をインストールしました。Composerもインストールしました。
次のようなExtensionも使えるようにしたいのですが、つまっています。
ext-bcmath,ext-ctype,ext-curl,・・・

ネット上でみたところ、PHPの用語でモジュールとExtension、ライブラリとあるようですが、
それぞれ違うものなのですか？

2023/04/30(日) 01:15:52.37

PHPの拡張ならそれを入れないと使えないのでは・・・
composerはあくまで自分の作るプログラムで使うライブラリを導入するもの

2023/05/12(金) 22:24:38.02

サーバーのバックエンドの*.phpはpost送信などで任意で呼び出して実行されますが
このバックエンドの*.phpで自発的に一定時間ごとにプログラムを駆動させることはできますか？
例えば1時間おきとか1日おきとかに規定プログラムを実行なんていうのは

2023/05/12(金) 22:30:23.15

cronに登録すればいいだけでは？
PHPをデーモンとして常駐させてその中で定期的に動かす方法もあるだろうけど

2023/05/12(金) 23:50:55.10

無限ループとsleep使ったスクリプトを起動させときゃいいけど
自分でコントロール出来ないサーバだと勝手にkillされるかもな

2023/05/13(土) 09:35:12.10

例えばWindowsならコマンドプロンプトで
「php.exe <そのファイル>」
と打てば実行できる(環境変数に入ってる前提で)

そういうことじゃないの？
あとはWindowsならタスクスケジューラとかLinuxならcronとかで、同じように実行すればいい

2023/05/18(木) 11:36:31.84

フロントエンドはJS、バックエンドはPHPってできるだけ切り離したい

バックエンドとしてDBからデータ受け取るためだけにPHP使うってありなのかな？
あと現状スクラッチ開発しかしたことがないからバックエンド向けのフレームワークも試してみたい

2023/05/18(木) 11:39:20.88

すればいいじゃん
がんばれ

2023/05/18(木) 12:33:14.63

言語はなんでもいいならphpなんて選ばない
普通はrubyかJavaかpythonだぞ
phpはやめとけ

2023/05/18(木) 12:43:42.00

Pythonは完全に対応しているサーバーが少ないみたい
Pythonとdjangoでバックエンド書く方法が自分にはまだわからない

2023/05/18(木) 15:55:36.70

>>576
バックエンドには通常PHPを使用するのでアリ
フレームワークはFuelPHPが良いね
フロントエンドのフレームワークはjQueryを使う

2023/05/18(木) 16:38:05.22

>>578
その３つの方が選ばないわｗ
PHPが一番楽だろｗ
それにPHPのスレでその返答はないわ
ゴミは消えろ

2023/05/18(木) 16:43:12.95

まあラクなのはphpやろなあ
ケースによって最適は異なるから、便利な言葉「場合による」

2023/05/18(木) 17:32:55.73

なんでも使える自社サーバーなのか、
レンタルサーバーのつもりかで選択肢かわるもんな

phpはだいたい使えるから仕方ない

2023/05/18(木) 19:26:52.18

VPSなら何だって使える

2023/05/19(金) 01:52:10.66

>>583
会社のサーバーがさくらのレンサバだから何でもかんでもPHPなんだよね

ごく小規模だからスクラッチ開発が基本だし
レベル低くて仕事で精一杯だしで何か独学するって余裕もないから、まずPHPの手軽さからわざと離れてJSでDOM操作は分けてみようかなぁと

2023/05/22(月) 01:29:49.15

別に言語はなんでもいいけど
クライアントJSから直接サーバのDBにはアクセスできないし
非同期でやる場合、だいたい>>576のようになるんじゃね

2023/06/10(土) 20:37:19.56

WSL2(ubuntu)にLaravelインスコしてみたけど
メモリ8G程度だときっついですね
docker desktopとかwindowsターミナル入れろとかこの辺は
aptでdocker入れたりubuntu直接起動したりすればおｋな感じですか？
とりあえずやってみてその方法でもいけたはいけたんですが（メモリも1Gぐらい減った）
ビルドしてるときの表示がバグったりちょっと不安要素がありました

2023/06/11(日) 08:50:59.31

メモリも問題だけど、たぶん最大の問題はファイルを配置した場所だと思うよ
・ソースコードをWSL2ディストリビューション領域内に配置する
で大幅に改善すると思う

2023/06/12(月) 08:08:55.93

httpリクエストで動的なサイトからデータ取得するのってやっぱり無理なんですかね？javascriptでhtmlが生成されるよなページんんだけど

2023/06/12(月) 10:00:10.61

無理ではない
curlやDOM操作のライブラリ自体は揃ってるんだから、後はあなたが頑張ってそのJavaScriptの動作を真似るだけ

2023/06/12(月) 10:25:34.03

おれなら生成はブラウザにやらせるかな
出来た頃合いを見計らってデータを盗む

2023/06/12(月) 10:27:10.81

例を示していただけませんか

2023/06/12(月) 10:29:59.61

javascriptは通常ブラウザが実行します。しかしhttpリクエストではブラウザを介さないためjavascript は実行されません。ヘッドレスブラウザなどを使えば動的なコンテンツを取得できますが、わたしの課題はhttpリクエストで動的ページからデータを取得することです

2023/06/12(月) 10:34:38.95

レスポンスを取得してからjavascriptを一回実行すればいいのかな？そんなことできるのかな

2023/06/12(月) 10:41:43.85

大変だね
ブラウザ禁止縛りプレイならまあ自分で頑張るしかないね

ていうかphantomjsって開発停止してんだな知らんかった

2023/06/12(月) 21:30:39.08

httpリクエストで動的なサイトからデータ取得するのってやっぱり無理なんですかね？javascriptでhtmlが生成されるよなページんんだけど

2023/06/12(月) 21:39:47.58

おまえLaravelスレのアラシだろ
うざいよ

2023/06/12(月) 22:12:16.13

>>596
puppeteerがいいんじゃない？

おれは使ったことないけど、phantomjsのメンテナが
「puppeteerあるならもうphantomjsなんかいらんわ」
って言いだして開発終了したらしいし、確かみてみろ

2023/06/12(月) 22:24:27.56

puppetterというものはヘッドレスブラウザを使えるようにしたライブラリであり、わたしはスクレイピングをしたいわけではありません。わたしの課題はhttpリクエストで動的なサイトからデータを取得することであり、ヘッドレスブラウザを使用してスクレイピングをしたいわけではありません

2023/06/12(月) 22:37:29.16

わたしがヘッドレスブラウザを使わない理由はデータの取得時間がかかるからです。またわたしはデータベースを使用しないことを前提としているので、取得したデータを保持することはありません。つまり度々データを取得することになる場合に都度ヘッドレスブラウザーを走らせる設計は現実的ではありません

2023/06/13(火) 11:41:46.36

>>600
これが各行ごとに良くわからないな

＞データの取得時間がかかるからです
何が原因で取得時間がかかるようになるのか
実測してそんなに差異が出たってコト？

＞データベースを使用しないことを前提としているので
DBなんか使わなきゃいいんじゃない？

＞度々データを取得することになる
同一データを扱うならキャッシュすればいいんじゃない？
PHPでだってアホに作れば度々データ取得しに行っちゃうと思うよ

＞現実的でありません
面倒くささ的にも自前でDOM構築する方が非現実的だよね

2023/06/13(火) 16:08:55.26

async awaitとfetch使ってデータ取得すれば良いじゃん

2023/06/13(火) 18:49:37.74

httpリクエストとスクレイピングでデータ取得の速度を比較する場合一般的にはhttpリクエストのほうが高速です。またわたしの想定では同一データではなく毎回違うクエリでリクエストすることが予想されます。

2023/06/13(火) 18:50:18.43

>>602
具体的にはどのような手順でそれらを使用しますか？