元スレ【PHP】Laravel【フレームワーク】 Part.3

みんなの評価 :

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

51 = :

>>50
javaも駄目
こういう外注はどうせSpring Bootばっかりやっていて
いざSpring Framework案件になったら全く何もできなくなる
今までこいつらができていたのは開発者が設定すべき内容を
Spring Bootが自動でやってくれていたからに過ぎない

55 = :

とりあえずこういう人とは一緒に働きたくないてのはわかる
外注さんにも選ぶ権利はある

56 = :

LaravelやSpringBootは駄目でSpringは良いの？
自動でやってくれるってのは駄目ってのを突き詰めていくと、
apacheやnginxを使わないでサーバーソフトウェアは自作しろとはならないのかな？
CentOS使わないで自作しろとか、高級言語使わないでアセンブラで作れとはならないのかな？

57 = :

Laravel信者ホイホイか、ここは。
まぁ、どこぞのエージェント経由の面談で「Laravelなら任せてください！」と張り切ると
逆効果な場合もあるってことだ。

58 = :

あほなの？
なんで組み込み任せるやつ探すのに、webのフルスタックエンジニア紹介させるんだよｗ
組み込みやってるやつ紹介するように依頼しろ。

で、そんなやつはスレチだわ。

59 = :

職人は意識高い系嫌いだろうけどどっちもプライドはクソほど高いよね

60 = :

今、掌田本の実践開発編読んでるけど意外と知らない事も多いな

61 = :

>>60
例えば？

62 = :

ストレージ関係の細かい事やらサービスとファザードの事やらイベント、スケジューラーやら
あとDBまわりだとついついrawで書いちゃうところを実はもっとちゃんとした書き方あったのかっていうのとか

知らなくても代替でどうにかなるような事だけどこれ使った方がスマートなつくりにできるんだろうなって感じ
まぁ公式ドキュメント全部読めば済む話ではあるんだけど使う機能の部分しかちゃんと読んでなかったんだよね

63 = :

現状PHPはLaravel使うかSymfony使うの２択だな
CodeIgniterはいいのかね？

64 = :

Laravelって部分的にSymfonyが使われてるとかよく言われてるけどSymfonyを知っておいた方がLaravelの深い部分を知る上で有利な事って何かある？

65 = :

ないね

66 = :

>>63
CodeIgniterはMVC的に管理はしたいけど、学習コストかけたくないって時期に便利に使ってた。
ほとんど素のphpで動くんで、学習は楽だったけど、いまさら使おうとは思わんかなぁ。
4が開発中みたいだけど、どうなんだろ。

67 = :

Laravelを勉強するにあたって2020年現在一番おすすめの
チュートリアルってありますか？

68 = :

>>67
Railsチュートリアル

69 :

🙄

70 = :

Laravel界隈殺伐としてんな

71 = :

Laravel界隈っていうかここだけだと思うけどね

72 = :

でもPHPフレームワークはLaravelが最強だよ

73 = :

PHP7.4で爆速になるとかほんとなん？

74 = :

古いマイグレーションファイルって消していいの？まだよく分かってないんだけどphp artisan magrateしたら最深のマイグレーションファイルが実行されるの？

75 = :

76 = :

>>74
いや消さないだろ
用途考えろよ

77 = :

消しちゃいかん
なんのためにup()とは別にdown()があるのか考えよう

78 = :

え？みんな消さないのか？

79 = :

君のように趣味で一人でやってる分には消していいかもね。
普通は消さないけど。

80 = :

マニュアルにも書いてあるから、疑問に思うならまずマニュアルを読んだほうがいいと思うよ。

http://readouble.com/laravel/6.x/ja/migrations.html

> マイグレーションとはデータベースのバージョンコントロールのような機能です。アプリケーションデータベースのスキーマの更新をチームで共有できるようにしてくれます。

> もしあなたが今まで、チームメイトに彼らのローカルデータベーススキーマに手作業でカラムを追加するよう依頼したことがあるなら、データベースマイグレーションは、そうした問題を解決してくれます。

81 = :

やるとしたら枯れたとこまでをリファクタリング目的で整理するくらいだな
ただまあスキーマ確認ならDBをプロットする方が確実だし普通は放置

82 = :

マイグレーション機能をなくすなくさないで頻繁に
Laravelコミッターが議論してるし将来的にはなくなるかもね

83 = :

俺もマイグレーションファイル消す派だったけどお前ら残してるの？

84 = :

リポジトリに残してあるなら消してもいいけど
環境再構築とかするときにないと困ることもあるかと思うぞ

85 = :

マイグレーションファイルを消してる人は環境の再構築や共有をどうやってるの？

86 = :

カラムぐらい自分で作れ。
フレームワークごときにDBを支配させるな。

87 = :

>>86
定義書見ながら環境構築用のクエリを自分で書けって意味？

88 = :

コードの履歴とDBの履歴は一致させておきたい
別々に管理するとDB変更のデプロイ漏れ多いんだよ

89 = :

いきなりリソースコントローラーでstoreしてredirectで同じクラス内のindexメソッドに移行してview表示すると404になるようになった
デバッグ環境構築してやってみるとuncaughtなfatal errorで流れ掴めん
controllerがMyResourceCntrollerのextends Controllerされてる行で見つからないと表示される
どうすればいいですか

91 = :

アクションメソッドからアクションメソッドにwith()で指定出来るようなセッションを持たせて推移させるにはどうすればいい？
出来ない？
storeからindexに移らせたいんだけど
web.phpに書かないといけないのかね
そもそも再利用性と過疎結合の丁度いい塩梅が分からない

92 = :

何言ってるか分からん

93 = :

>>92
コントローラーからコントローラーにセッションを持って移行したい場合一々web.php通らないといけないの？

94 = :

>>91
めっちゃ頭悪そう
まずアクションメソッドって何だよ、コントローラーアクションだろ。
storeとかindexってなんだよ、コントローラーのメソッドAとメソッドBだろ。
web.phpってなんだよ、ルーティング定義ファイルだろ。

つーか設計がおかしいんじゃ？って点に触れなければ、普通にそのstoreメソッドのしかるべきタイミングで$this->index()でメソッド呼べばいいんじゃないか？

95 = :

Sessionファサード使えばコントローラー云々とかルーター云々とか一切気にする必要ないけど

96 = :

>>94
煽り抜きで聞くがアスペか？

97 = :

>>95
これだわ
flash関数を使えば良いんだな
助かる

98 = :

ファサード全否定してるけどファサードって駄目なの？

http://www.slideshare.net/mobile/KenjiroKubota/laravelfacade

99 = :

Facade警察の話はもう語り尽くされただろ
使い方次第で良薬にも劇薬にもなる

100 = :

過去スレ見とくわ