[過去ﾛｸﾞ] 【PHP】Laravel【フレームワーク】 Part.2 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
128: 2019/04/30(火)12:58 ID:??? AAS
JOINの高負荷問題で通常の開発者にはあまり関係ないはず。
あれはGoogleとかAmazonクラスのWEBサービスじゃないと
発生しないんじゃないっけ
129: 2019/04/30(火)13:00 ID:U8oZvJd3(35/43) AAS
おまえらは、LaravelのスレッドでなぜJOINの話題を始めるのだ。
バカなのか？
130(1): 2019/04/30(火)13:00 ID:??? AAS
同時アクセスでJOIN高負荷ってなんだよ…。JOIN 高負荷 賞金でググってもなんも出てこないぞ。
131: 2019/04/30(火)13:00 ID:??? AAS
DBのJOIN云々とか
ActiveRecordの定義云々とか他でやれ
ここはLaravelのスレだから
132(2): 2019/04/30(火)13:02 ID:??? AAS
>>130
よく知らんけど多分日本語じゃ無理だろうな
133: 2019/04/30(火)13:03 ID:??? AAS
それもそうだな。終わりにしよう。いいネタは出たな。
134: 2019/04/30(火)13:03 ID:U8oZvJd3(36/43) AAS
まったく、俺様のように、Laravelの欠点や、対抗馬となるべき未来のフレームワークについて語れ。
135(1): 2019/04/30(火)13:05 ID:??? AAS
話を戻すけど>>73については何がいいたいの？
136(1): 2019/04/30(火)13:05 ID:??? AAS
>>132
けっきょく知らねーのかよw
お前は日本語で誰も話題にしてないRDBのJOIN問題に辿り着いてここで披露してるわけか。すごいな。
137: 2019/04/30(火)13:07 ID:??? AAS
未来のフレームワークについては別スレのほうがいいのでは
138: 132 2019/04/30(火)13:08 ID:??? AAS
>>136
俺は120じゃないけど日本語での検索ワードじゃ無理だろうなって思ったから言っただけだよ
139(2): 2019/04/30(火)13:13 ID:U8oZvJd3(37/43) AAS
>>135
んとさ、例えば
<label for="Volume">数量</label>
<input type="text" id="Volume" name="volume">
というフィールドのバリデーションでさ、
max:255
って、ちゃんと動くのか？ って話。
140: 2019/04/30(火)13:20 ID:??? AAS
integer|max:100 なら数値だし
string|max:100 なら文字数だし
volume[] なら要素数でバリデーションだしファイルならサイズだよ。
141: 2019/04/30(火)13:26 ID:??? AAS
>>139
文字列、数値、配列、ファイルに対して255以下ってのが働くね
HTML側がinput type="file"になった場合は
255キロバイト以下という判定に代わる
142: 2019/04/30(火)13:40 ID:??? AAS
>>139
動くよ
もし数値であることも判定したいならinteger付けたりとかだね
143(2): 2019/04/30(火)13:41 ID:U8oZvJd3(38/43) AAS
なるほど。一応、型は意識していると。
では、Aの商品の時は最大50個までで、Bの商品の時は100個までだけど、
クーポンを使ったときにはBの商品は20個限定、
みたいな処理は、どこにどうやって書くの？
144: 2019/04/30(火)13:49 ID:??? AAS
AvailableQuantitySpecificationクラス作って isSatisfiedBy($cart)メソッドの中にそのロジック実装して
$validator->after()の中でバリデーション。
145: 2019/04/30(火)13:52 ID:??? AAS
>>143
それもバリデーションに書くね。その場合条件付きバリデーションって
方法になる
146: 2019/04/30(火)13:56 ID:??? AAS
色々かけるな。
afterの中でバリデーションしてもいいし
sometimes使用して条件付きバリデーション使用してもいいし
147: 2019/04/30(火)13:57 ID:??? AAS
それはバリデーションじゃなくて制約、仕様なんだからバリデーションに書くなよ。
単体でテストできるようにクラスでも関数でもいいから分離しとけ。
148: 2019/04/30(火)14:00 ID:??? AAS
まさか学校の課題をここで聞いているんじゃなかろうな
149(3): 2019/04/30(火)14:01 ID:U8oZvJd3(39/43) AAS
ほーら、なんかいろいろ言い出した。
つまり、作ってるやつで書き方違うって事だ。
150: 2019/04/30(火)14:04 ID:??? AAS
>>149
そりゃ違うでしょ。各会社でコーディング規約が違うんだから。
同じ会社なのに書き方違ったら馬鹿だけど
151: 2019/04/30(火)14:05 ID:??? AAS
>>149
誰が書いても同じになるようにしたいってこと？
なんかあんまり実務でチーム開発したことなさそう。どんなフレームワーク使っても同じになるよ。チームでルールを決めるんだ。
152: 2019/04/30(火)14:06 ID:??? AAS
逆にそんなキチキチのフレームワークとか嫌なんだがw
レールの上を走り続けたい人向けフレームワークでもつくればいいじゃん
153: 2019/04/30(火)14:08 ID:??? AAS
実際の開発だとコーディング規約が定まっていてそれ通りに書くから
少なくとも開発チーム内では同じ書き方になるぞ
154(1): 2019/04/30(火)14:11 ID:U8oZvJd3(40/43) AAS
バカどもめ。
見えるぞ。お前たちの作ったアプリが３年後に産廃の山になる未来が見える。
155(3): 2019/04/30(火)14:15 ID:U8oZvJd3(41/43) AAS
そうだ、思い出した。もう一個聞きたいことがある。
公開サイトと管理画面を作る時、このLaravelではどのようにプロジェクトを作るつもりなのだ？
156: 2019/04/30(火)14:15 ID:??? AAS
>>154
チーム開発したことある？過去に5人以上のチームで自分が満足したシステム作り上げたことある？
たぶんひとりで自分が満足するものしか作ったことないんじゃないかな。
157: 2019/04/30(火)14:16 ID:??? AAS
>>149
会社？個人？
個人なら好き勝手に書けるけど会社なら規約があるはずだから
会社が決めた制約で書くはずだが。
158(1): 2019/04/30(火)14:17 ID:??? AAS
>>155
自分でnamespace分けてサブドメインルーティングすればいいんじゃないかな。それかマイクロサービスにするか。ノリシックにしてもいいよ。
そんなのフレームワークに決め手もらうことじゃなくて開発規模、対象を見て考えるもんだよ。
159: 2019/04/30(火)14:19 ID:??? AAS
まぁ1人でやるような小〜中規模案件でも使い勝手はいいフレームワークだと思うけどね
160(1): 2019/04/30(火)14:22 ID:??? AAS
>>155
それはどういう管理画面なの。
納品先のユーザが使用する管理画面？
それともアプリ製作者が使用する管理画面？
161(1): 2019/04/30(火)14:22 ID:U8oZvJd3(42/43) AAS
>>158
何を言っているのかわからないんだが、
公開サイトのファイルも、管理画面のファイルも、
全部同じプロジェクトの中に入ると言っているのか？
162(1): 2019/04/30(火)14:23 ID:U8oZvJd3(43/43) AAS
>>160
例えば、ネットショップを作るとする。
公開画面でユーザが買い物をする。
管理画面で注文について管理する。
当然双方での料金の計算ロジックは同じではなければならないから、
モデルに相当するものは共有したい。
どうするつもりか教えてくれ。
163: 2019/04/30(火)14:27 ID:??? AAS
例が具体的過ぎて学校の宿題か
今度実装するアプリについてここで聞いているように思えるｗｗｗ
164: 2019/04/30(火)14:30 ID:??? AAS
namespace分けろよ
\App\Models 共通のモデル
\App\Frontend\Http\Controllers
\App\Admin\Http\Controllers
こんな感じで別々にするんだよ。
165(2): 2019/04/30(火)14:31 ID:??? AAS
間違っても App\Http\Controllers\Admin,Frontend にするなよ。
166: 2019/04/30(火)14:32 ID:??? AAS
従来の方法で良いんでは
AdminController作ってログインユーザーのroleがAdminのみ受け入れる
167(1): 2019/04/30(火)14:33 ID:??? AAS
>>161
Laravel使ってないから参考にならないだろうけど講演で聞いた限りでは
YahooとAmazonは、買い物画面と管理者画面は同じプロジェクト内で作っている
168: 2019/04/30(火)14:37 ID:??? AAS
固定観念の塊って感じw
169: 2019/04/30(火)14:40 ID:??? AAS
>>155
無理に擦り寄って来なくていいってば
170: 2019/04/30(火)14:42 ID:??? AAS
一般画面と管理画面でnamespace分けるでしょ
171(1): 2019/04/30(火)14:44 ID:AFYaLSZi(1/5) AAS
こーれはまた、チンパジーだらけだな。
お前らのプロジェクトが火を吹きまくる未来が良く見えるぞ。
172: 2019/04/30(火)14:47 ID:??? AAS
namespace分ける馬鹿ばっかりだなぁ
だからお前らのアプリは産廃になるんだよ
173(1): 2019/04/30(火)14:55 ID:AFYaLSZi(2/5) AAS
>>167
そいつらは自分のところのシステムであるから如何様にも出来ようが、
お前達のプロジェクトがお前たちのさじ加減でどうにかなると良いのう。
はーはっはっは。
174(1): 2019/04/30(火)15:01 ID:??? AAS
>>173
自分は>>162の場合どのように設計するつもりなの？
175: 2019/04/30(火)15:07 ID:??? AAS
>>171
Laravel誕生のころからずっと業務システムに使ってるけど
Laravel製のプロジェクトで今まで火を吹いたことないな。
別プロジェクトのDjangoとFuelPHPは吹きかけたけど
176(2): 2019/04/30(火)15:13 ID:AFYaLSZi(3/5) AAS
>>174
勿論、そのように設計するに決まっておろう。
同じプロジェクト内に作るが、
別のサイト単位で作るのじゃ。
馬鹿め。
Laravelとやらにそれができるのか？
お前にサンが救えるのか。
177(1): 2019/04/30(火)15:21 ID:??? AAS
>>176
そりゃ確かにLaravelはできないね。Symfony2の方がきれいに作れそう。
178(1): 2019/04/30(火)15:48 ID:??? AAS
>>176
その作り方はLaravelでは無理ですね。
そもそもそういうサイト設計するならLaravelは候補にすら上らん
179(1): 2019/04/30(火)15:54 ID:??? AAS
Laravelで作った決済系のサイトだとこいつが有名ですね
外部ﾘﾝｸ:github.com
180: 2019/04/30(火)15:57 ID:??? AAS
サイト単位はLaravelでもできるぞ
181(2): 2019/04/30(火)15:57 ID:AFYaLSZi(4/5) AAS
>>177-178
では、上の方でnamespaceなどとほざいていたチンパンジーどもはなんであったのだ？
182: 2019/04/30(火)16:02 ID:??? AAS
>>179
このショッピングサイトのソースだとnamespace方式でやってるな
183(1): 2019/04/30(火)16:09 ID:??? AAS
>>181
現状最高だと思えるフレームワークは何ですか？
184(1): 2019/04/30(火)16:11 ID:AFYaLSZi(5/5) AAS
>>183
お前はLaravelとやらを使っておれば良い。
185: 2019/04/30(火)16:14 ID:??? AAS
普通に複数サイトもやってるけど
パッケージに分けなよ
186: 2019/04/30(火)16:16 ID:??? AAS
>>184
お前が未来のフレームワークについて語ろうって自分から
言ってきたんだろうが
187: 2019/04/30(火)16:18 ID:??? AAS
幼稚な嵐にかまうなよ……うれションして喜んでるだろうが
188: 2019/04/30(火)16:20 ID:??? AAS
Laravelスレってみんな技術力低すぎないか？
AFYaLSZi様の言っていることはもっともだと思うんだが
189: 2019/04/30(火)16:21 ID:??? AAS
様付けとかｗｗｗ
ID消して自演かよｗｗ
190: 2019/04/30(火)16:26 ID:??? AAS
様とかこいつ頭大丈夫か？
AFYaLSZiが一番技術力低いんだが
191(1): 2019/04/30(火)16:32 ID:??? AAS
>>181
Laravelはマルチプロジェクトの概念がないからnamespace で分けるんだよ。
パッケージの使い方としては正しい。ただ設定値はフロントと管理で共通だからな。まぁ普通はサブドメインを分けて、ルーティングも分ければマルチプロジェクトになるのでそれで十分だろ。
192: 2019/04/30(火)16:34 ID:??? AAS
このスレでまともなの俺とAFYaLSZiも含めて3〜4人ぐらいだな。
フレームワークに使われて自分の頭で考えるの放棄してるやつばっか。
193: 2019/04/30(火)16:53 ID:??? AAS
お前ら平成最後の日に何やってんだよ
日本人なら日本人らしくアニメ見るとか漫画読むとかゲームするとかしろよ
194: 2019/04/30(火)17:00 ID:??? AAS
俺、仕事しながら令和迎えるんだ
日本人は24時間365日仕事し続ける生き物だからね
日本人ぽいでしょ
あはははは
195: 2019/04/30(火)17:16 ID:??? AAS
頭いい人はららベルより素晴らしいオレオレフレームワーク開発してよぉw
196(1): 2019/04/30(火)17:39 ID:??? AAS
LaravelでDoctrine使ってる人いる？一度プロジェクト見た気がするんだか見つからない。
ActiveRecordよりEntityManagerのほうが集約コントロールしやすいので好きなんだが。
197: 2019/04/30(火)17:45 ID:??? AAS
Laravel+Reactはいいぞ
198: 2019/04/30(火)17:57 ID:??? AAS
このスレでまともなの俺とAFYaLSZiも含めて3〜4人ぐらいだな。
フレームワークに使われて自分の頭で考えるの放棄してるやつばっか。
199: 2019/04/30(火)18:05 ID:??? AAS
>>196
これのこと？
外部ﾘﾝｸ:www.laraveldoctrine.org
200: 2019/04/30(火)18:19 ID:??? AAS
露骨な自作自演始まったなw
201(1): 2019/04/30(火)20:07 ID:??? AAS
Laravelが他のフレームワークと比べて
勝っているところと負けているところは何？
202: 2019/04/30(火)20:41 ID:??? AAS
>>201
771 nobodyさん sage 2019/04/17(水) 08:51:04.13 ID:???
フルスタックなところかな。キャッシュ、シュケジューラ、ジョブ、ミドルウェア、認識、なんでも設定すればすぐ動く。英語で out-of-the-box って言うんだっけ？箱から出してすぐ使えるってやつ。
203: 2019/04/30(火)21:28 ID:??? AAS
誰も一般画面と管理画面の実装方法答えられないのかよ。
204: 2019/04/30(火)21:31 ID:??? AAS
そんな質問あったか？
205: 2019/04/30(火)21:35 ID:??? AAS
別人だが俺も>>191みたいにサブドメイン切って置いてるな
DB共通にしつつユーザー認証用のテーブルだけ別のものに差し替えて認証するようにしてる
206: 2019/04/30(火)21:36 ID:??? AAS
普通サブドメインだよな
207(1): 2019/04/30(火)21:43 ID:??? AAS
基本的にデバッグ時は8000番でやってるからルート以外に置くの面倒なんよね
管理者用の認証テーブル使いたい場合はテーブル作って管理画面用プロジェクトのapp/User.phpに
protected $table = 'administrators';
とか足しとけばそっちのテーブル見に行くようになるし
208: 2019/04/30(火)22:08 ID:??? AAS
>>207
auth.php に定義追加すれば Administratorモデルで認証できるよ。
マルチユーザで使えるように設計されてる。
209: 2019/04/30(火)23:56 ID:hZKQ99fS(1) AAS
>>143
SyouhinモデルにmaxKosuuを作ってええとカスタマーと1x複数になるのか？
商品を受け取ってバリデーションに渡すと
210: 2019/04/30(火)23:59 ID:??? AAS
お前らはLaravelで和暦対応どうした？
211: 2019/05/01(水)00:17 ID:??? AAS
和暦使うような糞なシステムはないよ
和暦は役所書類のみ、それ以外は西暦でってのはビジネスの常識
昔はごくごくたまに会員情報の生年月日で使うことがあったが今は個人情報をできるだけ入れない作りが主流
212: 2019/05/01(水)00:19 ID:??? AAS
大学関係の契約書だと和暦が多いね
213(1): 2019/05/01(水)00:40 ID:??? AAS
この前「最近点画にハマってる」って言ったら変な顔された
214: 2019/05/01(水)00:42 ID:FhfsDH51(1) AAS
TENGAにハマったまま平成が終わったのか
215: 2019/05/01(水)00:46 ID:??? AAS
「てんかく」な
216: 2019/05/01(水)01:06 ID:??? AAS
役所と近いところもまだまだ普通に和暦だよ
保育園とか学校とかね
事前に準備して4/2に対応終わったけど
217: 2019/05/01(水)07:54 ID:??? AAS
>>213
そんなん言葉のパッと聞きで何言ってるか分かんないに決まってるだろ
218(1): 2019/05/01(水)10:27 ID:??? AAS
>>165
こういう分け方なんで駄目なのか教えてもらえると嬉しい
219: 2019/05/01(水)11:12 ID:??? AAS
昨日の ID:AFYaLSZi様の技術力の高さは素晴らしいね
Laravelスレ全員が目指すべき人だよ
220: 2019/05/01(水)13:06 ID:??? AAS
令和時代のLaravel始祖の誕生であった
221(2): 165 2019/05/01(水)14:38 ID:??? AAS
>>218
疎結合にするためだな。FrontendとAdminはControllersの下位の概念ではないだろ？
AdminのためのModels,Http,Command
FrontendのためのModels,Http,Commandがあるんだ。
共通のものがあればAppの下でいい。
Adminをゴソっと消せば全てが消えるし、Frontendは何も関係せず動き続ける。お互いが交差しないようにパッケージを定義するんだ。
222: 2019/05/01(水)16:02 ID:??? AAS
>>221
どちらかというとプログラム初心者的な質問なのに答えてくれてありがとう
223: 2019/05/01(水)16:41 ID:gx0atIKK(1/2) AAS
>>221
Route::group['prefix'=>'admins']にしてるワイはやっぱおバカだったのか…
一応アドミニフォルダにコントローラはしまってるけど
224: 2019/05/01(水)16:44 ID:gx0atIKK(2/2) AAS
namespace見たらApp\Http\Controllers\Adminでワロタ…
225(1): 2019/05/01(水)17:14 ID:??? AAS
まぁ必ずやらなきゃいけないようなことでもないから自分のプロジェクトに合わせて好きに作ればいいよ。
namespaceをうまく分けるコツはuse文がなるべく少なくなるように定義するんだ。namespaceの上下内で完結するようにする。同レベルの横のnamespaceが3つも4つも出現したら何かが間違っている。
うまくやれば外部に露出するクラスがものすごく減る。
226: 2019/05/01(水)19:00 ID:??? AAS
>>225
自然と意識できるようになるまでまだ先は長いな…たぶん
227(1): 2019/05/01(水)22:15 ID:??? AAS
標準搭載されてるServiceManagerはオーバーライドできるけど、それやるとapp.phpを入れ替えないといけんのよね。
オーバーライドすんなってことなのかな。
でもログ周りとか微妙なんだよね。
228(1): 2019/05/01(水)22:18 ID:??? AAS
>>227
ServiceManagerってなんだっけ。ServiceProvider のこと？自分はガンガン置き換えてるよ。
229(1): 2019/05/01(水)22:23 ID:??? AAS
>>228
ああ、申し訳ないProvider。
logとかevent周りとか、こいつら置き換えて使ってる？
container作られる時に、結構余計なことしてるのよね。。
230(1): 2019/05/01(水)22:38 ID:??? AAS
>>229
defer付いてるやつは遅延ロードだから使わなきゃ動いてないよ。
logは標準の定義は残して使いつつ、logger.hoge の名前で別インスタンス追加して必要なときに取り出してる。
だいたいこれで事足りる。
標準のプロバイダを継承してカスタマイズしなきゃいけなかったのは認証とメールだけかな。
231: 2019/05/01(水)22:41 ID:??? AAS
お前らのオレオレカスタマイズ内容晒してけ
232(1): 2019/05/01(水)23:22 ID:??? AAS
>>230
deferついてるならそれでいいんだけど、kernelの流れで読み込まれる連中でも、要件によってはそれなりにいらない事してるんだよね。認証周りは同じくカスタマイズしたけど結構めんどかった。
Facadeのメリット活かしつつ機能を取捨選択してると魔改造になっちゃうんだよなあ。
233(1): 2019/05/01(水)23:35 ID:??? AAS
とても使いやすいし揃ってるframeworkだから、欲張ってしまうw
唯一eloquentだけはベンチとって愕然としたなー。あれは商用では使えないと思った。
234(1): 2019/05/01(水)23:36 ID:??? AAS
>>232
ある程度の諦めは必要かもねー。自分で使わないからってFacade削除したら内部とか追加したライブラリで呼んでたとかあるから標準機能は触らないのが無難かもしれん。
235: 2019/05/01(水)23:42 ID:??? AAS
>>234
そう。前者もあるけど特に後者が怖くて、標準の機能を削るって選択はなかなか出来ない。バージョンアップの時のオーバーヘッドがこれによって増大するから。ある前提で組まれてるものだから当然なんだろうけど。
削らないが無難。同意ですなあ
236: 2019/05/02(木)00:11 ID:??? AAS
ゴリゴリにチューニングするフレームワークではないので機能追加はしても削除はしない方針です。
パフォーマンスが必要になったら札束で殴るしかない。
237(1): 2019/05/02(木)00:17 ID:??? AAS
>>233
そんな遅い？使いにくいのは否定しないけど速度は他と大差ない気がする。
というよりORMでそこまで遅くなる部分があるとは思えないんだよな。
238: 2019/05/02(木)00:45 ID:??? AAS
>>237
ちょっと言葉足らずだった。パフォーマンスがシビアに要求されるシステムでは使えない、って感じ。もちろん速度とコーディングの利便性がある程度バーターになるのはわかるけど。
Doctrine単体とかとの比較なんで、同じレイヤーの他ORMとの比較ではないよ。
というのもLaravelでパフォーマンスチューニング、いくつかの案件でやったけどほぼほぼeloquentがボトルネックだった、ってとこからきてる
239: 2019/05/02(木)01:14 ID:??? AAS
Eloquentはマジックメソッドを多用したラッパーなんでオーバーヘッドはどうしても増える、PHP8のJITに期待
現状はcursor、バルクインサート、自作のバルクupsertなどで極力DBアクセス数を減らしとくしかない
240(1): 2019/05/02(木)01:27 ID:??? AAS
うーん、なんかイマイチ信じがたい話ではあるな。
マジックメソッドについてはクラスのメタデータキャッシュして2回目以降の呼び出しは速いはずだし。
例えばDoctrineはアノテーション使ってるし遅くなる要因はこっちの方が大きそう。
そもそもマッピングは枯れた技術ではあるので遅いなら他のフレームワーク参考にして同程度まで速度改善できるず。
フレームワーク全体で遅いなら理解できるけどORM単体でそんなに差がでるとは思えないな。クエリが遅いとかなら理解できるけど。
241: 2019/05/02(木)01:43 ID:??? AAS
>>240
いや、queryが遅いとかではなく、リレーションシップをCollectionで表現したり（出来たり）するじゃない。そもそもそういう使い方をされる事による速度の劣化であって、同じ使い方をすればdoctrineとかでも同じ結果になってただろうとは思う。
242: 2019/05/02(木)08:40 ID:vhQh3nzL(1/6) AAS
お前達はなんでそんなフレームワークを使っているんだ？
修行でもしているのか？
243: 2019/05/02(木)09:57 ID:??? AAS
使わない方が修行だと思うけどw
244: 2019/05/02(木)10:03 ID:??? AAS
構造的セキュリティ担保するの面倒だしな
245(2): 2019/05/02(木)10:56 ID:??? AAS
とりあえずmixがとても便利
246(1): 2019/05/02(木)11:35 ID:??? AAS
Laravelのhelperかなりいいよね。関数単体もそうだしCollectionも良い。
PHPはどうしても配列プログラミングになっちゃうからCollectionを使い倒してほしい。
247: 2019/05/02(木)11:44 ID:??? AAS
よく使うのはarray_get, pluck, tap, with,abort_if, throw_if, collectかな？
Collectionだとeach map first filter pluck。
248: 2019/05/02(木)11:47 ID:??? AAS
>>245
現行モダンフロントのシステム作る上でFirebaseやAWS Lambdaやみたいなサーバレス以外では最後の砦感あるよね
ExpressみたいなNode系フレームワークは新規に手を出すには日本語情報少な過ぎるし(日本語情報は大規模修正入る前の旧版ばかり)
249: 2019/05/02(木)11:57 ID:??? AAS
mixってwebpackのラッパもしくは代替みたいなもん？
250(1): 2019/05/02(木)12:33 ID:vhQh3nzL(2/6) AAS
>>246
全然知らねぇんだけど、helperってもしかしてHTMLの自動生成機能の事？
アホか。要るか、そんなもん。
251: 2019/05/02(木)12:35 ID:vhQh3nzL(3/6) AAS
mix? gulpでいいだろ。馬鹿か！？
252: 2019/05/02(木)12:37 ID:vhQh3nzL(4/6) AAS
なんでLaravelのアホは、ガラパゴスジャパンじゃあるまいし、独自規格ばっかつかいまくるんだよ。
253: 2019/05/02(木)12:38 ID:??? AAS
>>250
そのhelperではない
254(1): 2019/05/02(木)12:40 ID:??? AAS
標準規格がゴミだから標準をラップした独自規格作るんでしょ。
上下前次1-新書関写板覧索設栞歴
あと 748 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.189s*