TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
【Python】Webフレームワーク Djangoスレ Part2
俺専用の板
匿名掲示板Nch開発スレ part2【2chを越える】
組み込み型全文検索エンジンSenna
姫君スクリプト
JSP/Servletで構築されたサイト
【Apache】mod_rewriteについて語るスレ
正規表現道場 Part2
さまざまな言語仕様について熱く語る闘技場
ime.nuってどうなっているの?
【PHP】Laravel【フレームワーク】 Part.2
- 1 :
- テンプレ追加修正お願いします
Laravel
ウェブ職人のためのPHPフレームワーク
本家
https://laravel.com/
git
https://github.com/laravel
動画チュートリアル(英語)
https://laracasts.com/
日本語
http://laravel.jp/
書籍
Laravel リファレンス[Ver.5.1 LTS 対応] Web職人好みの新世代PHPフレームワーク
https://www.amazon.co.jp/gp/aw/d/4844339451
Laravelエキスパート養成読本[モダンな開発を実現するPHPフレームワーク!] (Software Design plus)
https://www.amazon.co.jp/gp/aw/d/4774173134
※前スレ
【PHP】Laravel【フレームワーク】
https://medaka.2ch.sc/test/read.cgi/php/1503683914/
- 2 :
- 魔法少女ララベル
https://www.nicovideo.jp/tag/%E9%AD%94%E6%B3%95%E5%B0%91%E5%A5%B3%E3%83%A9%E3%83%A9%E3%83%99%E3%83%AB
- 3 :
- createを使って更新するのとモデルをsaveして更新するのどう違うんやろ。
createの時だけguardedを設定しないといけないとかそもそも複数代入ってどういうことやねん。もーなんじゃいな
- 4 :
- あーのさー、Laravelってホントに便利なん?
ちらっと見てみた感じ、なんか、RoRとかCodeIgniterとかCakeとかがおかしてる間違いをそのまま引きずってる気がするんだけど?
これ、簡単なWEBアプリならRoRと同じでお手軽かもしんないんだけど
アプリが複雑になってくるとすぐ死なないか?
- 5 :
- 再投稿は甘え
- 6 :
- 前スレで叩かれたからって再レスかよww
- 7 :
- 6 名前:デフォルトの名無しさん[sage] 投稿日:2019/04/29(月) 02:19:44.72 ID:l/Mc2djO
Laravelとそれ以前のフレームワークの違いってLaravelはフロントエンド側のフレームワークとの連携機構がしっかりしてるから
PHP側のControllerはリクエストに応じてDBの読み書きさえやってればあとの制御はフロント側任せにできるとこだと思うんよね
https://mevius.2ch.sc/test/read.cgi/tech/1555718306/6
- 8 :
- Laravel-Mixは便利
- 9 :
- >>7
だから、アプリが複雑になるとどうせフォットコントローラになるんだろ
って言ってるんだが。
RoRとかCakeとかといっしょで爆裂Controller生成機じゃないか?
いつになったらこれじゃダメだって気づくんだ?
- 10 :
- フォットコントローラwwwwwwww
ファットだろwwww
- 11 :
- 複雑化した時に肥大化しないControllerモデルがあるのか?
まぁ表示制御をフロントに任せる限りはバックエンド側はシンプル、フロントエンドは規模なりのサイズになるわけだけど
- 12 :
- >>11
前スレでも言ったけどその時点でLaravelはダメなんだよ。
というかRoR、Cake、Laravel、Symfonyこれらみんなダメ
- 13 :
- 細かい処理はコントローラーから別ファイルの関数呼び出すだけにしてるから
複雑な処理のあるコントローラーも20行ぐらいで収まっているぞ、俺の場合
- 14 :
- 実際ガチのWEBシステムをLaravelで構築しているときって
どういう作りになってるのか見てみたい。
誰かオープンソースでgithubに上げてないのかな
- 15 :
- フロントエンドフレームワーク利用手順
・Node.js未導入の場合
# yum install nodejs
# npm install -g n
# n latest
# npm install -g npm
Vue.jsを使う場合
$ npm install
$ npm run watch
Reactを使う場合
$ php artisan preset react
$ npm install
$ npm run watch
後はresources/js内のファイルを編集すれば自動ビルド
- 16 :
- Laravelをガチで有意義に使うならVueかReactの習得は必須だと思うんよね
バックエンド側でやること殆どないからイチイチフロントとバックで分業するほどでもないと思うけど
- 17 :
- 今後もVueが活発になったら
laravelはAPIのみって感じが主流になりそうだね
- 18 :
- ガッツリ組むならReactの方が後の再利用性はいいと思う
- 19 :
- うちはjQueryとBootstrapでゴリゴリだわ
- 20 :
- 正直脱Bootstrapもやってみたいけど他のCSSフレームワークで何がいいかイマイチ分からんのよね
- 21 :
- >>11
よー分からん。一番でっかくなるのはモデルじゃないんか?
素人だから複雑なシステムはわからんけどコントローラが痩せたらモデルがでっかくなりつつある
- 22 :
- >>12
だから比較対象になるダメじゃない例がないと考察のしようがないだろ
例を挙げろよ例を
- 23 :
- >>22
自演乙
- 24 :
- 自演も何も理想的なモデルって一体何なわけ?
- 25 :
- >>21
書く量が変わるわけではないでしょ。
どこに書くかが変わるだけだから、どこかが減ればどこかが増えるのは仕方ない。
- 26 :
- BootstrapをベースにscopedにSCSS書けるのが便利過ぎて他に移行する気が起きない
- 27 :
- Laravelはもはやスタンダードでしょ
- 28 :
- >>25
なるほど。大事なのは後で読んだ時に分かり易いことでそれでいいんだな。
- 29 :
- Controller肥大化させん為にMiddlewareとかViewComposerとか幾つか回避策もあるんだけどね
- 30 :
- >>29
そういう、わけのわからん独自のアーキテクチャで何とかしようとするのやめれ。
- 31 :
- middlewareにするなら汎用化してくれないとロジックが取っ散らかるので慎重に
- 32 :
- 四の五の言わずに表示系は全部フロントフレームワークにすりゃいいんだよ
- 33 :
- >>11
よー分からん。一番でっかくなるのはモデルじゃないんか?
素人だから複雑なシステムはわからんけどコントローラが痩せたらモデルがでっかくなりつつある
- 34 :
- ミスった
- 35 :
- ミドルウェアが独自のアーキテクチャとかマジで言ってるんです?
- 36 :
- なんか無知を晒してるヤツ何人か居るがまぁ同一人物なんだろうね
- 37 :
- たとえララベル使わなくてもコードは肥大化するじゃん
- 38 :
- アーキテクチャとかフレームワークとかミドルウェアみたいなのは全然気にならないんだけど
BootstrapとかLaravelとかjQueryとかみたいな固有名をカタカナで書いてるの見るとなんか「うわっ」って思っちゃうんだよね
なんでだろ
- 39 :
- >>35
そうだよ。だって、本来のmiddlewareって、そういうもんじゃないもん。
Laravelが勝手に言ってる概念じゃん。
- 40 :
- Laravelがっていうよりもサーバーサイドプログラミング全般で使われる言葉じゃないか?
NodeのExpressでも同じ様にMiddlewareってあるし多分RoRにもDjangoってあるだろ
単にOSに対してのミドルウェアと違う様に見えるだけで相対的な意味ではやっぱミドルウェアだろ
- 41 :
- そんな言い分認めない。
- 42 :
- >>40
もっとまともな言い訳考えてこい
- 43 :
- だいたい、MVCどこ行ったんだよ。
うちのMVCでは手が足りないのでmiddlewareさんを助っ人に呼びましたってか?
そんなポンコツ、設計し直せ。
- 44 :
- あ、オレ、もしかして今核心ついた?
そういうことやってるからしょっちゅうでかい互換性のないアップデートかけてる?もしかして。
- 45 :
- 結構大規模にやってるけどドメインロジックはPOPOのサービス層に書いてるしコントローラは薄く保てる
そもそもMVC2とかただのUIアーキテクチャじゃん
ある程度複雑になればそれぞれのレイヤ、特にMの中身も設計する必要があるのは当然でしょ
- 46 :
- >>22
>>>12
>だから比較対象になるダメじゃない例がないと考察のしようがないだろ
>例を挙げろよ例を
これあったら誰か教えて
- 47 :
- どうせオレオレフレームワークが最強って言いたいだけなんだろうけどな
そういう奴に限ってユーザー認証用のパスワードをDBに平文で持つとかいう愚かな事やってる
- 48 :
- >>45
>ある程度複雑になればそれぞれのレイヤ、特にMの中身も設計する必要があるのは当然でしょ
おまえは本当に分かってないな。
複雑化してきた時の設計をユーザーに委ねてたらフレームワークの意味なくなるだろ。
そういう時の事まで考えて提示して初めてフレームワークなんだよ。
たとえば>>13みたいな事をさ、フレームワークとして提供すんの。
勿論、そのままやったら馬鹿だけどな。
CakePHPが流行ってた頃さ、ModelはDBにアクセスする物と誤解されて
それ以外が全部Controllerに書かれてファットコントローラーだらけになったのな。
で「CakeはDBにアクセスしないModel“も”作れるのに」って言い張ってたやつがいたけど、
根本的に、そういう設計が狂っちゃってんだよ。
- 49 :
- >>47
お前のレベルが低すぎる事だけは、その発言でよーくわかった。
- 50 :
- 現にここまで理想的なモデルとしての具体例・対案が一切出てない件
- 51 :
- >>50
は? オレ、前にヒント出しといたけど?
- 52 :
- まったく、>>50は馬鹿だなぁ。
- 53 :
- ID消すの忘れてますよ
- 54 :
- なんで消さなきゃいけないの?
- 55 :
- くだらない事考える暇あるならVue.jsなりReactなり習得してMVVMで作れば解決じゃん
なんか異論があるなら受け付けるけど
- 56 :
- もしかして、ただの連投を自演だと思ったとか?
本当にバカだなぁ。
- 57 :
- >>55
底抜けのバカが現れた。
- 58 :
- >>57
あなたのいう欠点を克服しているフレームワークは何?
それと比較してみたいんだが
- 59 :
- githubのスター獲得数が最高だから他のフレームワークと比べて
一番評価されているのでは
- 60 :
- みんなLaravelが優れていると思っているからgithubで最高評価もらってるし
大規模システムにも採用されているんだろう。
- 61 :
- おまえはPoEAA読み直してこい。ARは数あるパターンのひとつであって銀の弾丸ではない。データアクセスの抽象化が目的だ。
MVCに拘りすぎるのもやめろ。あれはステートフルなGUIアプリケーションの概念であってステートレスなウェブには合わない概念も多い。AndroidやiOSにはまだまた有用だが。
ソフトウェア構築の肝は疎結合だ。これが実現できるならオレオレ設計で全く問題ない。
フレームワークが担うのはHTTP入出力やデータアクセスなどどんなシステムでも利用する機能の共通化だけだ。ロジックが複雑化してきたときの助けにはならない。そこは自分とメンバーのスキルと規模によって良い方法を考えろ。
- 62 :
- バカが、レベルの低いフレームワークに引きずられて長文で語ってる。
- 63 :
- だったらフレームワークなんか使わずに全て自分で書けばいいだけやんw
オレオレフレームワークが最高なんだろ
このスレに常駐してる理由が分からんw
- 64 :
- バカ、逆ギレ。
- 65 :
- やっぱ、爆裂コントローラー生成機という見方は正しかったって事か。
使えんな、こんなもん。
- 66 :
- せっかく長文で書いてやったんだから反論頼むよ。おれこういう議論好き。
世の中しょぼいエンジニアしかいないから口が悪い奴でも楽しい話できるなら付き合うよ。
- 67 :
- ただの荒らしだよ
反論できるような知識もない
- 68 :
- フルスタックフレームワークはフルスタックエンジニアのためのフレームワーク
- 69 :
- 連投して議論じゃなく勝利宣言しかできないキッズはキッズ向けの板に行った方がいいと思うんよね
- 70 :
- まぁあらしの課題感は間違ってないと思うよ。議論にはならないけど。
ファットコントローラは世間的にも話題になったしファットモデルも同じく。
自分はDBアクセスなしのPOPOオブジェクトをたくさん作るのが好きだけど、それは小規模チームだから。大規模になると破綻する。
一方でJavaのSeasarみたいに大規模チームでワークするフレームワーク作った人たちもいたし。
- 71 :
- >>66
んーとさ、前スレだったか、上の方だったかにさ、
「Symfonyに何も学ばなかったのか?」って書いたじゃん。
Symfonyは個々の要求をさばくのにActionを使っていて、
それぞれを別のActionに分けることでControllerが肥大するのを防いでいた。
>>13みたいなのを、フレームワークの仕組みとして提供していた。
(褒められるのはそのくらいだったように記憶しているけど)
よくあるダメなフレームワークの典型のもう一つが、
Viewは描画をする場所なので、ロジックを書いてはいけないとしているところ。
だから、View=テンプレートみたいなアホみたいなことをしてしまう。
実際には描画に関する分岐やループというものはあって、
そういうのをテンプレート内でやろうとすると、
デザイナが手を出せない代物になってしまって破綻する。
つまり、大規模になると破綻する。
Laravelにそういうところのケアがあるようにはとても見えない。
ActiveRecordのような実装もダメ。
前スレでも言ったけど、テーブルに結びつくORMはJOINが困難になるので
RDBという資産をまるで生かせなくなってくる。
「いまどきは取ってきたのをアプリ側で処理するのが流行りだ」
とかキチガイが言っていたが、そういうことするからコードがゴミクズのようになるし、
ちょと複雑な処理をするとクソ遅くてメンテ不能になってくる。
流行りなんじゃなくて、それしか出来ないからそうしているだけ。
とにかく、どのフレームワークもRoRに引っ張られすぎ。
- 72 :
- >>71
それBladeテンプレートの仕様確認してから言ってる?
- 73 :
- それから、よくあり過ぎて頭いたくなってくるんだけどさ、
https://readouble.com/laravel/5.5/ja/validation.html
public function store(Request $request)
{
$validatedData = $request->validate([
'title' => 'required|unique:posts|max:255',
'body' => 'required',
]);
// ブログポストは有効
}
この、max:255 って単位はなんだ?
どっかでちゃんと分けてるんだよな? よく読んでないから知らないけど。
言ってる意味、分かるか?
- 74 :
- >>72
してない。現段階ではする気も起きない。
既にTwigっていう優秀なテンプレートエンジンが存在するのに、
わざわざBladeとかいうわけのわからん独自テンプレートを持ち込んでくる神経が
そもそも理解できない。
- 75 :
- あとDBに関してはこれ
https://readouble.com/laravel/5.8/ja/database.html
https://readouble.com/laravel/5.8/ja/queries.html
- 76 :
- >>75
「これ」が、何? 論旨を言えないバカ?
- 77 :
- 頭の固い老害ってとこだろうな
確認もせずにTwigが云々語っちゃう辺りはその典型
- 78 :
- >>77
ねぼけてんなぁ。Laravelでしか使われんBladeごときが、
Twig様に勝てるわけねーだろ。
- 79 :
- 流石に検索系でよっぽど単純な操作をやる場合以外でORMなんてそう使わんだろ
挿入、更新、削除なら積極的に使った方がシンプルになるだろうけど
- 80 :
- >>79
だからさ、エロなんとかと別のクエリビルダと、使い分ける設計がクソだって言ってるの。
そしたら、ActiveRecordパターンなんかダメに決まってんだろ。
(エロなんとかがActiveRecordパターンなのかよくしらんけどさ)
もうちょっと、頭使って作れって話。
- 81 :
- こいつが作った超イケてるフレームワークがGitHubに出てくる日を待つかw
- 82 :
- 別のクエリビルダの方は、SELECT結果はstdClassになっちゃいまぁす、とかさ。
そしたら、結果のオブジェクトになんかメソッド仕込むとかできねーだろ。
ActiveRecordはフォーマッタ仕込んだり
極端な話、オブジェクト自体にバリデーション埋め込むことだってできるけど、
stdClassじゃただデータ持ち運ぶ事しかできんじゃねぇか。
- 83 :
- Symfonyがいいって言うんならSymfony使ってればいいじゃん
別にそこを否定はせんよ
なんでわざわざ他所に喧嘩売りに来るのかその神経が分からん
- 84 :
- 急に進んでたから面白い議論でも始まったかと思ったら低脳が湧いて釣られたやつらがいただけだった
みんなちゃんとNGしとけよ
- 85 :
- >>82
データをDBに書き込む時にはバリデーション必要だけど
既に保存されたデータを検索して表示する過程にバリデーション必要か?
- 86 :
- >>83
ボケナス、褒められるのはそこだけだったって言ってんだろ。
つかえるか、あんなポンコツ。
- 87 :
- >>85
フォーマッタはあったら便利だろ。
- 88 :
- 先のことをさぁ、考えて、作るんだよ。
>>85くん。
- 89 :
- >>71
まずオレの意見から言うとSymfonyは素晴らしい。けど理想を追い求めすぎて複雑。Laravelはバランスが良くて小規模アプリは最高。ただしEloquentはクソ。Doctrine持って来い。
Laravel触ってみるといいよ。勘違いしてる部分も多そうだし。
Actionの部分はService Containerを調べて。
Viewの話はロジックというのは業務ロジックのことで、例えばこの会員はAランクなので付与率5%、それ以外は1%というような話でこれはViewじゃなくてモデルに書きましょうということだ。表示のための分岐はいくらでも書いて問題ないよ。
最近のARはJOINしてもうまくマッピングしてくれるようになってる。各ORMがN+1問題をどう解決してるかコード読め。Doctrineはコードがきれいだぞ。
クエリビルダとエロは別々のものじゃなくてビルダの上位レイヤがエロだ。普通はエロだけでよい。withとlazy loadの仕組みである程度速度のコントロールはできる。
RoRとLaravelが似てるのは否定しない。Symfonyは別の問題を解決しようとしてるから用途が違う。果物ナイフとノコギリを比べるようなもんだ。
- 90 :
- >>71
「いまどきは取ってきたのをアプリ側で処理するのが流行りだ」
は確かGoogleが推奨しているコーディング方式だね。
GoogleのWEBサービスは全部このやり方で実装されている。
- 91 :
- >>73
Request生で使う奴はいないでしょ。
普通はフォームリクエスト使ってそっちで宣言する
- 92 :
- >>90
そりゃGoogleはGCP売りたいんだからそう言うだろ。RDBを使わないシステムをターゲットにしてるんだから。
RDB使ってそんなことしてたらクソプログラマ認定されるぞ。
ぐーぐるさまが言ってるからって盲目的になるのは感心しないな。
- 93 :
- アスペルガー特有の強い拘り
- 94 :
- JavaのSpringFrameworkのJPAや
PythonのDjango
Ruby on Rails
Laravel
Symfony
等々みんなActiveRecord方式採用しているってことは
それで十分システムを構築できているんでしょう。
- 95 :
- >>89
>Viewの話はロジックというのは業務ロジックのことで、
>例えばこの会員はAランクなので付与率5%、
>それ以外は1%というような話で
>これはViewじゃなくてモデルに書きましょうということだ。
それをやめろって言ってんだ、ボケ。
なんで還元率適用後の値についてまでモデルが面倒見なきゃいけないんだ。
それはおまえ、社長が「よしこのお客さんには10%値引きしろ」って言ったら、
従業員が「社長、それはいくらになるんですか?」って言ってるようなもんだぞ。
馬鹿なのか?
- 96 :
- >>91
おまえは何を言っているのだ?
- 97 :
- >>94
採用してないよ。JPAとSymfony/Doctrineは違う。もう一回調べて。
- 98 :
- >>92
大勢でアクセスされた際のJOIN高負荷問題がどのDBもまだ未解決だから
大規模だとJOIN使わない方式が推奨されてるってだけじゃないの?
PostgreSQLやMySQLやOracleとかでJOIN高負荷問題の対策チームが
個別に存在しているぐらいだし
- 99 :
- >>94
つくるだけなら、な。
で、更改のたびにプログラマがヘドロのようになってるはずだ。
- 100 :
- MariaDBはわからんけど
- 101 :
- >>89
>表示のための分岐はいくらでも書いて問題ないよ。
それもやめろっって何回言わせんだ。
デザイナが触れなくなるだろーが。
- 102 :
- >>95
ん?おまえは還元率の計算をViewでやってるの?
ECサイトでポイントを表示するケースって、カートとか確認画面とかメルマガでDM送るときにこの商品を買ったら50ポイントです!とかあるけど、全部のビューに書いてる?変更するときどうすんの。
- 103 :
- >>97
JPAはOracleのJava Dayイベントで
ActiveRecord方式ってOracleの中の人が言ってるぞ
- 104 :
- >>98
経験上大量レコードからJOINで大幅にレコード件数減らせるんなら減らした方が低負荷になるはずだけどなぁ
間違ってたらスマン
- 105 :
- >>101
いやデザイナーに実コード触らせるとかやめろよ。そんなやり方
デザイナーから上がってきたhtmlはコーダーが実環境にマージ・適用した方が全体でみて低リスクだし低コストになる
- 106 :
- >>98
なんで世の中JOINが遅いことになってるんだろうな。最近のARしか知らないプログラマはほんと軟弱だわ。
JOINが遅いのは設定と設計とクエリが悪いの。その対策チームはJOINを無くすために存在してるんじゃなくて、設計とクエリを見直してパラメータを調整して速いJOINにするために存在してるの。対策した後もJOINを使うの。
- 107 :
- >>102
>87
>>85
>フォーマッタはあったら便利だろ。
>88
>先のことをさぁ、考えて、作るんだよ。
>>85くん。
加えて、Twigには、FilterとFunctionという便利なものもある。
おまえは、石器時代の人間か?
- 108 :
- >>105
おまえのアプリは作ったら作ったまんまか?
おまえ、サーバ側の改修やってるときに、
デザイナが書いたHTMLやCSSの面倒見たいか?
物好きだなぁ…。
- 109 :
- >>103
JPA自体はエンティテイにデータアクセスの機能は持たせない。レコードと1対1の構造はARっぽいが同じではない。
拡張のActiveJPAとかいうのと混同してるのでは?
- 110 :
- >>106
いや違う。複数からアクセスされたときに単純なクエリにかかわらず
JOINが高負荷になってしまう問題が存在していて
それを解決するために各チームが存在している。
解決したソースコードを提供した人には賞金が授与されるけど
未だ誰もこれを解決できるソースを提供できた人はいない
- 111 :
- >>107
でも>>82読んだ限りだとARにフォーマッタ仕込みたいんだろ?
Twigはテンプレートエンジンの方じゃんなんでごっちゃになってるの?
- 112 :
- >>106
それは、下手くそなバカがJOINするからだ。
アホが書いたくそぐっちゃぐちゃのSQLを1/3に減らしたら
実行速度が1/10になりましたとか、普通にあるだろ。
あいつらは実行計画の見方もしらない。
JOIN前にSELECTで絞りまくったほうが速いとすら思っている。
- 113 :
- >>108
変に分からんヤツに荒らされて狂うくらいなら自分でやった方がいいに決まってるだろ
- 114 :
- >>109
Oracleの中の人が言ってるんだから混同してないでしょ。
もしくは今後実装予定の機能をポロっと言ってしまった可能性もあるけど
- 115 :
- >>107
FiltetとFunctionはだいたいどのテンプレートエンジンにもあるが、あれはヘルパであってロジックの置き場じゃないぞ。
- 116 :
- >>111
「たい」んじゃなくて、仕込「める」と言っているんだ。
OOPというのはそういうものだ。
- 117 :
- >>114
いいからググれ。JPAの仕様とActiveJPAの仕様を読んでこい。違いがわかるから。
- 118 :
- >>115
寝ぼけ過ぎだ。
お前が言っていた
>表示のための分岐はいくらでも書いて問題ない
場所、
それが、その場所だ。いい加減に気づけ。
- 119 :
- >>110
うーん皆の話に齟齬があるみたいだからその複数アクセスの規模を明示して?
多分秒間10や20くらいじゃそうならないよね?
- 120 :
- >>112
それはJOINじゃなくてクエリの書き方の問題でしょ。
ここで言われてる複数アクセス時のJOIN高負荷は賞金がかけられてるやつだから
DB本体のコーディングの問題。
- 121 :
- >>113
まったく、だからお前のやっている仕事はスケールしないんだよ。
連投禁止かかりはじめたから、しばらくポイント貯めるぞ。
- 122 :
- Java Dayに参加したことあるけど確かにOracleはJPAを
ActiveRecord方式と言ってたな。
- 123 :
- >>120
何言ってんのか意味不明。JOINのアルゴリズムはほぼ確立されていて、データ量が膨大であれインデックスがメモリに乗ってCPUに余裕があればどんなに大量のアクセスがあっても理論上は遅くならない。Btreeの仕組みとインデックスの用途、実行計画について調べてこい。
- 124 :
- >>117
Oracleが発言してるんだからそれOracleに言って来いよ。
どうせOracleがActiveRecordを勘違いしてるんでしょ。
- 125 :
- >>120
言いたいことは大体分かったけど
なんかソースみたいな記事持ってこないと噛み付いてる人は納得しないと思うよ
- 126 :
- >>123
遅くなる問題があるからわざわざ専門チームがいて
賞金もかけられれるんでしょ。
PostgreSQLやMySQLの開発チームの中に
JOIN問題を解決する対策チームがいるからそいつらに言って
間違い正して来いよ。
- 127 :
- ARの定義知ってんの?
1レコード1エンティテイ
エンティテイがDBアクセスを担う
この二つを満たしてるものがActiveRecordたぞ。JPAは当てはまらない。Oracleが言ったからって信じるなよ。
- 128 :
- JOINの高負荷問題で通常の開発者にはあまり関係ないはず。
あれはGoogleとかAmazonクラスのWEBサービスじゃないと
発生しないんじゃないっけ
- 129 :
- おまえらは、LaravelのスレッドでなぜJOINの話題を始めるのだ。
バカなのか?
- 130 :
- 同時アクセスでJOIN高負荷ってなんだよ…。JOIN 高負荷 賞金でググってもなんも出てこないぞ。
- 131 :
- DBのJOIN云々とか
ActiveRecordの定義云々とか他でやれ
ここはLaravelのスレだから
- 132 :
- >>130
よく知らんけど多分日本語じゃ無理だろうな
- 133 :
- それもそうだな。終わりにしよう。いいネタは出たな。
- 134 :
- まったく、俺様のように、Laravelの欠点や、対抗馬となるべき未来のフレームワークについて語れ。
- 135 :
- 話を戻すけど>>73については何がいいたいの?
- 136 :
- >>132
けっきょく知らねーのかよw
お前は日本語で誰も話題にしてないRDBのJOIN問題に辿り着いてここで披露してるわけか。すごいな。
- 137 :
- 未来のフレームワークについては別スレのほうがいいのでは
- 138 :
- >>136
俺は120じゃないけど日本語での検索ワードじゃ無理だろうなって思ったから言っただけだよ
- 139 :
- >>135
んとさ、例えば
<label for="Volume">数量</label>
<input type="text" id="Volume" name="volume">
というフィールドのバリデーションでさ、
max:255
って、ちゃんと動くのか? って話。
- 140 :
- integer|max:100 なら数値だし
string|max:100 なら文字数だし
volume[] なら要素数でバリデーションだしファイルならサイズだよ。
- 141 :
- >>139
文字列、数値、配列、ファイルに対して255以下ってのが働くね
HTML側がinput type="file"になった場合は
255キロバイト以下という判定に代わる
- 142 :
- >>139
動くよ
もし数値であることも判定したいならinteger付けたりとかだね
- 143 :
- なるほど。一応、型は意識していると。
では、Aの商品の時は最大50個までで、Bの商品の時は100個までだけど、
クーポンを使ったときにはBの商品は20個限定、
みたいな処理は、どこにどうやって書くの?
- 144 :
- AvailableQuantitySpecificationクラス作って isSatisfiedBy($cart)メソッドの中にそのロジック実装して
$validator->after()の中でバリデーション。
- 145 :
- >>143
それもバリデーションに書くね。その場合条件付きバリデーションって
方法になる
- 146 :
- 色々かけるな。
afterの中でバリデーションしてもいいし
sometimes使用して条件付きバリデーション使用してもいいし
- 147 :
- それはバリデーションじゃなくて制約、仕様なんだからバリデーションに書くなよ。
単体でテストできるようにクラスでも関数でもいいから分離しとけ。
- 148 :
- まさか学校の課題をここで聞いているんじゃなかろうな
- 149 :
- ほーら、なんかいろいろ言い出した。
つまり、作ってるやつで書き方違うって事だ。
- 150 :
- >>149
そりゃ違うでしょ。各会社でコーディング規約が違うんだから。
同じ会社なのに書き方違ったら馬鹿だけど
- 151 :
- >>149
誰が書いても同じになるようにしたいってこと?
なんかあんまり実務でチーム開発したことなさそう。どんなフレームワーク使っても同じになるよ。チームでルールを決めるんだ。
- 152 :
- 逆にそんなキチキチのフレームワークとか嫌なんだがw
レールの上を走り続けたい人向けフレームワークでもつくればいいじゃん
- 153 :
- 実際の開発だとコーディング規約が定まっていてそれ通りに書くから
少なくとも開発チーム内では同じ書き方になるぞ
- 154 :
- バカどもめ。
見えるぞ。お前たちの作ったアプリが3年後に産廃の山になる未来が見える。
- 155 :
- そうだ、思い出した。もう一個聞きたいことがある。
公開サイトと管理画面を作る時、このLaravelではどのようにプロジェクトを作るつもりなのだ?
- 156 :
- >>154
チーム開発したことある?過去に5人以上のチームで自分が満足したシステム作り上げたことある?
たぶんひとりで自分が満足するものしか作ったことないんじゃないかな。
- 157 :
- >>149
会社?個人?
個人なら好き勝手に書けるけど会社なら規約があるはずだから
会社が決めた制約で書くはずだが。
- 158 :
- >>155
自分でnamespace分けてサブドメインルーティングすればいいんじゃないかな。それかマイクロサービスにするか。ノリシックにしてもいいよ。
そんなのフレームワークに決め手もらうことじゃなくて開発規模、対象を見て考えるもんだよ。
- 159 :
- まぁ1人でやるような小〜中規模案件でも使い勝手はいいフレームワークだと思うけどね
- 160 :
- >>155
それはどういう管理画面なの。
納品先のユーザが使用する管理画面?
それともアプリ製作者が使用する管理画面?
- 161 :
- >>158
何を言っているのかわからないんだが、
公開サイトのファイルも、管理画面のファイルも、
全部同じプロジェクトの中に入ると言っているのか?
- 162 :
- >>160
例えば、ネットショップを作るとする。
公開画面でユーザが買い物をする。
管理画面で注文について管理する。
当然双方での料金の計算ロジックは同じではなければならないから、
モデルに相当するものは共有したい。
どうするつもりか教えてくれ。
- 163 :
- 例が具体的過ぎて学校の宿題か
今度実装するアプリについてここで聞いているように思えるwww
- 164 :
- namespace分けろよ
\App\Models 共通のモデル
\App\Frontend\Http\Controllers
\App\Admin\Http\Controllers
こんな感じで別々にするんだよ。
- 165 :
- 間違っても App\Http\Controllers\Admin,Frontend にするなよ。
- 166 :
- 従来の方法で良いんでは
AdminController作ってログインユーザーのroleがAdminのみ受け入れる
- 167 :
- >>161
Laravel使ってないから参考にならないだろうけど講演で聞いた限りでは
YahooとAmazonは、買い物画面と管理者画面は同じプロジェクト内で作っている
- 168 :
- 固定観念の塊って感じw
- 169 :
- >>155
無理に擦り寄って来なくていいってば
- 170 :
- 一般画面と管理画面でnamespace分けるでしょ
- 171 :
- こーれはまた、チンパジーだらけだな。
お前らのプロジェクトが火を吹きまくる未来が良く見えるぞ。
- 172 :
- namespace分ける馬鹿ばっかりだなぁ
だからお前らのアプリは産廃になるんだよ
- 173 :
- >>167
そいつらは自分のところのシステムであるから如何様にも出来ようが、
お前達のプロジェクトがお前たちのさじ加減でどうにかなると良いのう。
はーはっはっは。
- 174 :
- >>173
自分は>>162の場合どのように設計するつもりなの?
- 175 :
- >>171
Laravel誕生のころからずっと業務システムに使ってるけど
Laravel製のプロジェクトで今まで火を吹いたことないな。
別プロジェクトのDjangoとFuelPHPは吹きかけたけど
- 176 :
- >>174
勿論、そのように設計するに決まっておろう。
同じプロジェクト内に作るが、
別のサイト単位で作るのじゃ。
馬鹿め。
Laravelとやらにそれができるのか?
お前にサンが救えるのか。
- 177 :
- >>176
そりゃ確かにLaravelはできないね。Symfony2の方がきれいに作れそう。
- 178 :
- >>176
その作り方はLaravelでは無理ですね。
そもそもそういうサイト設計するならLaravelは候補にすら上らん
- 179 :
- Laravelで作った決済系のサイトだとこいつが有名ですね
https://github.com/Laracommerce/laracom
- 180 :
- サイト単位はLaravelでもできるぞ
- 181 :
- >>177-178
では、上の方でnamespaceなどとほざいていたチンパンジーどもはなんであったのだ?
- 182 :
- >>179
このショッピングサイトのソースだとnamespace方式でやってるな
- 183 :
- >>181
現状最高だと思えるフレームワークは何ですか?
- 184 :
- >>183
お前はLaravelとやらを使っておれば良い。
- 185 :
- 普通に複数サイトもやってるけど
パッケージに分けなよ
- 186 :
- >>184
お前が未来のフレームワークについて語ろうって自分から
言ってきたんだろうが
- 187 :
- 幼稚な嵐にかまうなよ……うれションして喜んでるだろうが
- 188 :
- Laravelスレってみんな技術力低すぎないか?
AFYaLSZi様の言っていることはもっともだと思うんだが
- 189 :
- 様付けとかwww
ID消して自演かよww
- 190 :
- 様とかこいつ頭大丈夫か?
AFYaLSZiが一番技術力低いんだが
- 191 :
- >>181
Laravelはマルチプロジェクトの概念がないからnamespace で分けるんだよ。
パッケージの使い方としては正しい。ただ設定値はフロントと管理で共通だからな。まぁ普通はサブドメインを分けて、ルーティングも分ければマルチプロジェクトになるのでそれで十分だろ。
- 192 :
- このスレでまともなの俺とAFYaLSZiも含めて3〜4人ぐらいだな。
フレームワークに使われて自分の頭で考えるの放棄してるやつばっか。
- 193 :
- お前ら平成最後の日に何やってんだよ
日本人なら日本人らしくアニメ見るとか漫画読むとかゲームするとかしろよ
- 194 :
- 俺、仕事しながら令和迎えるんだ
日本人は24時間365日仕事し続ける生き物だからね
日本人ぽいでしょ
あはははは
- 195 :
- 頭いい人はららベルより素晴らしいオレオレフレームワーク開発してよぉw
- 196 :
- LaravelでDoctrine使ってる人いる?一度プロジェクト見た気がするんだか見つからない。
ActiveRecordよりEntityManagerのほうが集約コントロールしやすいので好きなんだが。
- 197 :
- Laravel+Reactはいいぞ
- 198 :
- このスレでまともなの俺とAFYaLSZiも含めて3〜4人ぐらいだな。
フレームワークに使われて自分の頭で考えるの放棄してるやつばっか。
- 199 :
- >>196
これのこと?
https://www.laraveldoctrine.org/
- 200 :
- 露骨な自作自演始まったなw
- 201 :
- Laravelが他のフレームワークと比べて
勝っているところと負けているところは何?
- 202 :
- >>201
771 nobodyさん sage 2019/04/17(水) 08:51:04.13 ID:???
フルスタックなところかな。キャッシュ、シュケジューラ、ジョブ、ミドルウェア、認識、なんでも設定すればすぐ動く。英語で out-of-the-box って言うんだっけ?箱から出してすぐ使えるってやつ。
- 203 :
- 誰も一般画面と管理画面の実装方法答えられないのかよ。
- 204 :
- そんな質問あったか?
- 205 :
- 別人だが俺も>>191みたいにサブドメイン切って置いてるな
DB共通にしつつユーザー認証用のテーブルだけ別のものに差し替えて認証するようにしてる
- 206 :
- 普通サブドメインだよな
- 207 :
- 基本的にデバッグ時は8000番でやってるからルート以外に置くの面倒なんよね
管理者用の認証テーブル使いたい場合はテーブル作って管理画面用プロジェクトのapp/User.phpに
protected $table = 'administrators';
とか足しとけばそっちのテーブル見に行くようになるし
- 208 :
- >>207
auth.php に定義追加すれば Administratorモデルで認証できるよ。
マルチユーザで使えるように設計されてる。
- 209 :
- >>143
SyouhinモデルにmaxKosuuを作ってええとカスタマーと1x複数になるのか?
商品を受け取ってバリデーションに渡すと
- 210 :
- お前らはLaravelで和暦対応どうした?
- 211 :
- 和暦使うような糞なシステムはないよ
和暦は役所書類のみ、それ以外は西暦でってのはビジネスの常識
昔はごくごくたまに会員情報の生年月日で使うことがあったが今は個人情報をできるだけ入れない作りが主流
- 212 :
- 大学関係の契約書だと和暦が多いね
- 213 :
- この前「最近点画にハマってる」って言ったら変な顔された
- 214 :
- TENGAにハマったまま平成が終わったのか
- 215 :
- 「てんかく」な
- 216 :
- 役所と近いところもまだまだ普通に和暦だよ
保育園とか学校とかね
事前に準備して4/2に対応終わったけど
- 217 :
- >>213
そんなん言葉のパッと聞きで何言ってるか分かんないに決まってるだろ
- 218 :
- >>165
こういう分け方なんで駄目なのか教えてもらえると嬉しい
- 219 :
- 昨日の ID:AFYaLSZi様の技術力の高さは素晴らしいね
Laravelスレ全員が目指すべき人だよ
- 220 :
- 令和時代のLaravel始祖の誕生であった
- 221 :
- >>218
疎結合にするためだな。FrontendとAdminはControllersの下位の概念ではないだろ?
AdminのためのModels,Http,Command
FrontendのためのModels,Http,Commandがあるんだ。
共通のものがあればAppの下でいい。
Adminをゴソっと消せば全てが消えるし、Frontendは何も関係せず動き続ける。お互いが交差しないようにパッケージを定義するんだ。
- 222 :
- >>221
どちらかというとプログラム初心者的な質問なのに答えてくれてありがとう
- 223 :
- >>221
Route::group['prefix'=>'admins']にしてるワイはやっぱおバカだったのか…
一応アドミニフォルダにコントローラはしまってるけど
- 224 :
- namespace見たらApp\Http\Controllers\Adminでワロタ…
- 225 :
- まぁ必ずやらなきゃいけないようなことでもないから自分のプロジェクトに合わせて好きに作ればいいよ。
namespaceをうまく分けるコツはuse文がなるべく少なくなるように定義するんだ。namespaceの上下内で完結するようにする。同レベルの横のnamespaceが3つも4つも出現したら何かが間違っている。
うまくやれば外部に露出するクラスがものすごく減る。
- 226 :
- >>225
自然と意識できるようになるまでまだ先は長いな…たぶん
- 227 :
- 標準搭載されてるServiceManagerはオーバーライドできるけど、それやるとapp.phpを入れ替えないといけんのよね。
オーバーライドすんなってことなのかな。
でもログ周りとか微妙なんだよね。
- 228 :
- >>227
ServiceManagerってなんだっけ。ServiceProvider のこと?自分はガンガン置き換えてるよ。
- 229 :
- >>228
ああ、申し訳ないProvider。
logとかevent周りとか、こいつら置き換えて使ってる?
container作られる時に、結構余計なことしてるのよね。。
- 230 :
- >>229
defer付いてるやつは遅延ロードだから使わなきゃ動いてないよ。
logは標準の定義は残して使いつつ、logger.hoge の名前で別インスタンス追加して必要なときに取り出してる。
だいたいこれで事足りる。
標準のプロバイダを継承してカスタマイズしなきゃいけなかったのは認証とメールだけかな。
- 231 :
- お前らのオレオレカスタマイズ内容晒してけ
- 232 :
- >>230
deferついてるならそれでいいんだけど、kernelの流れで読み込まれる連中でも、要件によってはそれなりにいらない事してるんだよね。認証周りは同じくカスタマイズしたけど結構めんどかった。
Facadeのメリット活かしつつ機能を取捨選択してると魔改造になっちゃうんだよなあ。
- 233 :
- とても使いやすいし揃ってるframeworkだから、欲張ってしまうw
唯一eloquentだけはベンチとって愕然としたなー。あれは商用では使えないと思った。
- 234 :
- >>232
ある程度の諦めは必要かもねー。自分で使わないからってFacade削除したら内部とか追加したライブラリで呼んでたとかあるから標準機能は触らないのが無難かもしれん。
- 235 :
- >>234
そう。前者もあるけど特に後者が怖くて、標準の機能を削るって選択はなかなか出来ない。バージョンアップの時のオーバーヘッドがこれによって増大するから。ある前提で組まれてるものだから当然なんだろうけど。
削らないが無難。同意ですなあ
- 236 :
- ゴリゴリにチューニングするフレームワークではないので機能追加はしても削除はしない方針です。
パフォーマンスが必要になったら札束で殴るしかない。
- 237 :
- >>233
そんな遅い?使いにくいのは否定しないけど速度は他と大差ない気がする。
というよりORMでそこまで遅くなる部分があるとは思えないんだよな。
- 238 :
- >>237
ちょっと言葉足らずだった。パフォーマンスがシビアに要求されるシステムでは使えない、って感じ。もちろん速度とコーディングの利便性がある程度バーターになるのはわかるけど。
Doctrine単体とかとの比較なんで、同じレイヤーの他ORMとの比較ではないよ。
というのもLaravelでパフォーマンスチューニング、いくつかの案件でやったけどほぼほぼeloquentがボトルネックだった、ってとこからきてる
- 239 :
- Eloquentはマジックメソッドを多用したラッパーなんでオーバーヘッドはどうしても増える、PHP8のJITに期待
現状はcursor、バルクインサート、自作のバルクupsertなどで極力DBアクセス数を減らしとくしかない
- 240 :
- うーん、なんかイマイチ信じがたい話ではあるな。
マジックメソッドについてはクラスのメタデータキャッシュして2回目以降の呼び出しは速いはずだし。
例えばDoctrineはアノテーション使ってるし遅くなる要因はこっちの方が大きそう。
そもそもマッピングは枯れた技術ではあるので遅いなら他のフレームワーク参考にして同程度まで速度改善できるず。
フレームワーク全体で遅いなら理解できるけどORM単体でそんなに差がでるとは思えないな。クエリが遅いとかなら理解できるけど。
- 241 :
- >>240
いや、queryが遅いとかではなく、リレーションシップをCollectionで表現したり(出来たり)するじゃない。そもそもそういう使い方をされる事による速度の劣化であって、同じ使い方をすればdoctrineとかでも同じ結果になってただろうとは思う。
- 242 :
- お前達はなんでそんなフレームワークを使っているんだ?
修行でもしているのか?
- 243 :
- 使わない方が修行だと思うけどw
- 244 :
- 構造的セキュリティ担保するの面倒だしな
- 245 :
- とりあえずmixがとても便利
- 246 :
- Laravelのhelperかなりいいよね。関数単体もそうだしCollectionも良い。
PHPはどうしても配列プログラミングになっちゃうからCollectionを使い倒してほしい。
- 247 :
- よく使うのはarray_get, pluck, tap, with,abort_if, throw_if, collectかな?
Collectionだとeach map first filter pluck。
- 248 :
- >>245
現行モダンフロントのシステム作る上でFirebaseやAWS Lambdaやみたいなサーバレス以外では最後の砦感あるよね
ExpressみたいなNode系フレームワークは新規に手を出すには日本語情報少な過ぎるし(日本語情報は大規模修正入る前の旧版ばかり)
- 249 :
- mixってwebpackのラッパもしくは代替みたいなもん?
- 250 :
- >>246
全然知らねぇんだけど、helperってもしかしてHTMLの自動生成機能の事?
アホか。要るか、そんなもん。
- 251 :
- mix? gulpでいいだろ。馬鹿か!?
- 252 :
- なんでLaravelのアホは、ガラパゴスジャパンじゃあるまいし、独自規格ばっかつかいまくるんだよ。
- 253 :
- >>250
そのhelperではない
- 254 :
- 標準規格がゴミだから標準をラップした独自規格作るんでしょ。
- 255 :
- >>254
おまえ、gulp様のどのへんがゴミなのか、Yeah!
- 256 :
- gulp使うんだったらwebpack使ったほうがまし
- 257 :
- javascriptツールの話は他スレでやれよ
- 258 :
- >>256
同意
- 259 :
- おーおー、JavaScriptも満足に使えないバカどもが必死だな。
そんなんでどうやってフロントを作るつもりだ?
- 260 :
- ぐ・・・Grunt・・
- 261 :
- そもそもJavaScript使わない。
- 262 :
- 未だにWindowsXPとかがあるところに収めてるシステムなので
JavaScriptは使ったことないな
- 263 :
- 俺の会社はapiサーバとしてLaravel使用してるけど
フロントは別会社が製作してるからJavaScriptは気にしたことないな
- 264 :
- 僕の会社はAngular-CLIちゃん!!
- 265 :
- うちの会社はvue-cliちゃんだぞ
- 266 :
- j・・・jQueryだけ・・・・
- 267 :
- map,tapは本当よく使うなあ。
Laravel使ってる現場だとたまにpredis見るけど、何故モジュールを使わないのーと思う。
- 268 :
- 結論:Laravelスレの作ったプログラムは1か月で産廃
- 269 :
- メルカリでメルpay決済の祭り開催中!!
https://i.imgur.com/c5Rf0BQ.jpg
https://i.imgur.com/HgXj0Vc.jpg
※ポイントバックは翌日付与
更に初回会員限定で300pが貰えるキャンペーン実施中(iDで1p1円で利用可能、ポイントバックも対象)
【300pの入手方法】
・新規登録の最終ページでwelcome code
「BVUQWA」
を入力して300pゲット
・メルpay設定する
完了
うおおおお
- 270 :
- イキッテるやつほんと老害だなw
一緒に仕事したらトラブルメーカーだろうな
- 271 :
- >>270
ぷっ、小者w
- 272 :
- お前らのレス見てるとお前らがいかに産廃プログラムを書いているかがわかる。
どうせ1か月ぐらいでお前らのソフトウェア産廃になってるんだろう?
- 273 :
- LaravelはJSONを返すAPIに特化させて外観はフロントフレームワークで書いた方が絶対いい
- 274 :
- ワイはいまapp()->make()がマイブーム
うんコード化に拍車がかかる。
- 275 :
- >>274
主にどの辺りで使ってる?Controllerなのがサービスクラス的なものなのか。
- 276 :
- >>275
気が向いた場所。tinkerが一番多いけどモデルにもある。うんコードだから参考にはならないぞ
- 277 :
- >>275
requestを処理するのにそうゆうのもありなのか
- 278 :
- 誰か、Facades警察の話でもしてくれや
- 279 :
- 正規表現でもう心が折れそうになってる
- 280 :
- Larabelと全然関係ないとこで躓いてんな
- 281 :
- らぁらゔぇぅ
- 282 :
- >>273
そういうデータ中心の用途だと、どうしてもPHPから離れたくなっちゃうんだよねw
- 283 :
- >>282
なに使うの?
- 284 :
- Node系のフレームワーク使えればそっちの方がいいのかも知れんけど
実用するには日本語情報が少ないんよね
サーバレスは無料で収まらない規模になったら従量課金鬼だし
- 285 :
- APIとして使うだけもLaravelが工数すくなくてすげー楽じゃね?
jsで使うのってexpressとかでしょ?
- 286 :
- >>273
この用途だとしてもフロントでセッションとか使うならうわものはLaravelの方が楽じゃないかな
- 287 :
- Laravelの軽量版でAPI向けのやつって何だっけ?
- 288 :
- https://lumen.laravel.com/
- 289 :
- それだ。あなたが神か?
- 290 :
- いいえ私は神ではありません
- 291 :
- APIだけだからとか気にせず
普通にlaravel使えばいい
- 292 :
- なあにLaravem MixとかあるしViewを使わないのなんて想定済みよ
- 293 :
- laravelがphpとjavascriptを
縦横無尽に使える両刃の剣と聞いたんだけど
web.appからアクションindexを呼び出して、
「$this->name=文字列」をいれたら
アクションwriteの$this->nameが別のモノに
なってるとか、オブジェクト指向としてオカしすぎる。
---MainController.php---
namespace 略
use Illuminate\Http\Request;
class MainController extends controller{
public function index(){
$this->name="TAROU";
/*処理A*/
}
}
class public write(){
$who=$this->name;
/*処理B*/
}
}
---wep.app---
Route::get('/test','MainController@index');
Route::post('/test','MainController@write');
- 294 :
- $whoはいったい、なぜnullになるの?
そして、getとpostでそれぞれのアクションを呼び出した時に
どうやったら、同じインスタントを共有できるの
教えてエロい人。
- 295 :
- >オブジェクト指向としてオカしすぎる。
自分スキルは自分が一番理解できてるはずなのに
こういう発言を平気で出来る精神が気にくわん!
- 296 :
- とりあえずLaravelというかフレームワークの動作の紐解きからしようか
そういや最近はHowTo本ばっかで内部の仕組みまで解説した本ってC言語のコンパイル & リンクくらいだなあ
要望を文字通りに実現するならwebsocketサーバーなどで起動しっぱなしにしたところに
ルーティングが機能するように変態実装をしなきゃならんと思う
- 297 :
- >>293
根本的に書き方間違えてる
viewを返すにしろjsonを返すにしろちゃんとcontrollerにreturn掛け
その例じゃ何をreturnしてるか分からん
- 298 :
- てか状態を持ちたいなら
引数にRequest $request入れて
$request->session->put('name','tarou');
$request->session->get('name');
だろ
Requestがないってエラーで怒られたら
上のuse句に
use Illuminate¥Http¥Request;
って足せ
- 299 :
- >>293
当たり前じゃね?
カオスなのは自分の頭かと
- 300 :
- 呼び出してとか書いてるから
Route::get('/test','MainController@index');
でindex()が実行されてると思ってるんだろ
- 301 :
- Laravelを知らないというよりHTTPの状態管理とセッションの概念を知らなそう
- 302 :
- 半角の¥って文字化けってかエスケープ掛かるのな
- 303 :
- AWSで1時間半はまったわ
ENV反映されてないだけだった
artisanのキャッシュクリアコマンドで一瞬で解決したわ
キーないぞボケ!とかわかりやすいエラー帰ってこないのかよ
- 304 :
- そのミスとAWSは何の関係ないし
まあ、ありがちなミスではあるが
- 305 :
- 君らはまったくもってシニアだ
- 306 :
- 何が言いたいんだいジュニアよ
- 307 :
- >>303
あんな従量課金で請求が青天井なサービスよく使えるな
- 308 :
- >>293
>class public write(){
これ何ぞ?
- 309 :
- >>307
いくらなんでもそれは無知すぎ
- 310 :
- ¥
¥
円
\
\
- 311 :
- \
\
- 312 :
- >>293
えー…
- 313 :
- 我ながらすごい事に気づいたんだが。。
tinkerでapp()->make()すれば今書いてるクラスにエラーあるかちょびっとわかる
- 314 :
- xdebug()をtinkerで呼べば詳細なコールスタックも見れた
- 315 :
- これaxiosだけで完全遷移させようとすると
requestが正常応答のときは毎回$request->session()->get('_token')取ってきてaxiosのcsrfトークン更新しないといけないんだね
422エラー応答の時は要らないみたいだけど
- 316 :
- axiosって何。
なんかさぁ、なんでLaravelは中二こじらせたみたいに
機能の推測ができないわけのわからん名前をごろごろつけてんの?
エロなんとかとかパルメザンだかなんかとか。
- 317 :
- フロントの話じゃね?
- 318 :
- axiosは超有名なんですが
ララベル関係ねえし
- 319 :
- tokenって取り方色々あるね
フォームに直接仕込む
metaに仕込んだのをJSで取る
cookieに仕込まれてるのをJSで取る
と最近知った
axios自体にrequest前に処理挟む機能とかあるし
そこでheaderにぶち込むとか
- 320 :
- axios知らないとかエアプかよ
- 321 :
- フロントエンドやらない人は知らんと思うぞ
- 322 :
- プロジェクト全体としてフロント使わんならSymfonyでやった方がいいんじゃないか?とすら思う
プロジェクトとしては使ってるならコミュニケーションとってなさすぎ
- 323 :
- Laravelって時代遅れなの?
- 324 :
- >>323
時代遅れなのは間違いない。それでもおれは使うけど。
- 325 :
- >>323
PHP自体が時代遅れなだけやで
- 326 :
- 確かにPHPも嫌いじゃないけど好きな言語使ってええで言われたらGo使うかな
- 327 :
- Goとかwwwwwwwwwww
- 328 :
- 確かに今はPHPからPythonへの過渡期ではあるけど何年かかることやら
まだまだ圧倒的にPHPが多いね
- 329 :
- Go笑う意味が分からんな
PHPが時代遅れとも思わないが
- 330 :
- Go言語ってそんないいのか?
あれ使うんだったらpython選ぶ
- 331 :
- Gopherくんを愛でろ
ついでにD言語くんも愛でろ
- 332 :
- Laravelってファットコントローラになりやすいよね
- 333 :
- >>330
マイクロサービス用フレームワークが活発だけど数が多すぎて決定打が無い、今のところGinとEchoが人気
フルスタック用にRevelがあるけど旬が過ぎた感、一応日本でも使ってる会社があるのをどっかの勉強会で聞いた
ちなみにどちらもホットリロードに対応してるんでコンパイルの手間は気にしなくていい
デプロイの際はexeなもんでプロセス復旧の仕組みを導入しなきゃだけどDocker-Composeのrestartオプションでいけてる
動的型付け言語がやれLinterだ型だ単体テストだ言ってるのを尻目にコンパイルをポンでまだ消耗してるの?という気持ちに
動的型付け言語がボトルネックはDBだからと言いながらJITや型で高速化!とダブスタしてるのを尻目にコンパイルしてそれ以上の速度に
- 334 :
- Goの話をなぜLaravelスレで・・・・
- 335 :
- facebookのhackってどうなの?
- 336 :
- 予言するとPHP8がなんだかんだで最強。で、またCakeが復権する。
- 337 :
- セミコロン省略できんってマ?
- 338 :
- マジで?
- 339 :
- オワコン化したニコニコを拠り所にしているのが実にファルコムらしいな
オワコンの上にパンツ規制で絶望してるんだろうがリィンさんみたいに状況を見極めつつ見届けて話し合ってる内にハーレムに
なるかもしれんし加藤と近藤を信じてクソゲ制作に邁進してくれよ
- 340 :
- すげぇ誤爆だなぁ…
- 341 :
- >>340
誤爆したぐらいで一々うるさい。
それとも俺ら閃の軌跡反省会スレに喧嘩売ってるのか?
- 342 :
- 必死すぎw
- 343 :
- >>332
お前いつもそれ言ってるな
- 344 :
- >>343
初めてなんだけど
- 345 :
- 自演乙
- 346 :
- >>343
おっと長文きちゃった
悔しかったねぇ
- 347 :
- 今どきファルコム云々言ってるやつって相当のおっさんだろw
- 348 :
- 信者このスレまできて必死すぎだろうw
- 349 :
- LaravelでControllerがファットになるのはフロントコーディングができない無能
- 350 :
- どういうこと?
- 351 :
- 「その必要は無いわ」のワンパターンのレベルって「お爺ちゃん、さっきご飯食べたでしょ」ってレベルの
演出考えてる奴が認知症かと疑ってしまったからなあ
エンタメのゲームでこういう歪んだモノ見せられると認知症の入った老害と物言えぬイエスマンの若手
しか居ない歪な会社なんだなとは思うわ
- 352 :
- ????
- 353 :
- まぁ社員が必死にこんなところで啓蒙キャンペーンをやってるのは判ったよw
実際に手抜きだらけでパンツ以外に力入れてないからこの会社って馬鹿だろってコケにされてるってだけの話なんだが
その自覚が無いところがファルコムの救いようが無いところだけどさ
- 354 :
- いや、このスレでファルコムなんかに感心あるやつなんか一人を除いてだれもいないぞw
当事者なんか来るわけもないし
- 355 :
- イース9の爆売れ確定は言いすぎだろう
内容次第でどうなるか分からんしね
- 356 :
- なんでLaravelスレでその話題なのか
- 357 :
- >>356
VIPに、安価で指定されたスレに関係ないことを書き込むスレが立ってる
- 358 :
- Laravelスレはファルコムだった?
- 359 :
- ??? ?????? ?????? ?????? ????? ?? Laravel?
- 360 :
- せめてPhalconスレでやれや
- 361 :
- LaravelAPIにしてVueメインでCRUD作ったけど難度高いわ
Laravelでだけで処理するよるより1.5倍くらい難度上がった
難しいだけでなく保守性がダダ下がりするのがきつい
- 362 :
- >>361
もうちょっと詳しくおしえてください
保守性がダダ下がりするというのはんだごて
どのような部分でしょうか。
- 363 :
- それよりも、はんだごての部分について詳しく
- 364 :
- ごめん、予測変換での誤字だとは思うが、はんだごてがツボってしまってやばい
- 365 :
- PHPとJSが複雑に絡み合うし保守性下がるのは仕方ないっしょ
- 366 :
- むしろ疎結合になるんじゃ
Laravel-MixでもせいぜいbladeにVue用にid="app"のDOM仕込むくらいだし
- 367 :
- その部分だけ見たら疎だろうけどそれ以外にも諸々あるだろ
JSライブラリの管理問題も出てくるし、ブラウザごとの挙動違いチェックとかも煩雑
- 368 :
- >>361
Reactでやったらわりといい感じになったけどな
確かにイニシャルに掛かる手間的なコストは大きいけど後の再利用性は結構高いと思う
- 369 :
- フロントを変えたところで、普通のユーザーに見せても、なにが変わったの?というつれない反応しか返ってこないんだけどな。
- 370 :
- CSSフレームワークまで入れ替えればそこそこ変わるよMaterial UIなりVuetifyなり
- 371 :
- >>370
コロ助かよ
- 372 :
- , ────- 、
/ /⌒ ヽ ⌒ヽ\
/ , -|/ ・|・ \| 、 ヽ
/ / ` ─ ●ー ′ ヽヽ
l / ── | ─ | 「CSSフレームワークまで入れ替えればそこそこ変わるよMaterial UIなりVuetifyなり」
| / ── | ─ |
| l ── | ─ l
l | / ̄ ̄ ̄ ̄`ヽ /
ヽ ヽ (_____ノ /
>━━━━━ O━━─( _ )
/ / ヽ /
- 373 :
- てめぇは違うぞ青ダヌキ
- 374 :
- ww
- 375 :
- コロ助じゃないww
- 376 :
- ww
- 377 :
- _, ._
( ・ω・)
○={=}〇,
|:::::::::\, ', ´
.wwし w`(.@)wwww
- 378 :
- >>377
そのAA何でキャンディーを地面に転がしてるの?
- 379 :
- 草刈り機で草刈ってるんだよ
- 380 :
- え?
- 381 :
- え?
- 382 :
- おう!
- 383 :
- AA下手くそすぎだろwww
- 384 :
- 俺もキャンディーだと思ったwwwwwww
そうかよく見れば芝刈りか
- 385 :
- 大草原不可避
- 386 :
- 難解なコード
- 387 :
- 黄昏のコード
- 388 :
- 東ザナはアイドルの歌がどうとか幼馴染がどうとか手垢の付いた内容のオンパレードでやっててアクビが出た
閃もストーリーが稚拙で演出もワンパターンばかりでやってて眠かったわ
メインが10代20代って言ってるけど単に手抜きを若者向けに分かり易く(安直に)しましたってだけだろ
- 389 :
- Laravelすれが52chで一番面白いスレかもしれない
- 390 :
- 間違えた2chhhスレです
- 391 :
- おまえら、まだLaravelなんか使ってるの?
- 392 :
- もちのろんさ!
- 393 :
- あと5年はlaravel生きるよ
- 394 :
- ラーララ ラララ ラーララ ラララ
- 395 :
- セキスーイハウスー
- 396 :
- 俺社謹製のフレームワークが、凄まじいレベルに到達し始めている。
Laravelとかもう、ゴミッカス以下にしか見えない。
- 397 :
- >>396
例えば?
- 398 :
- >>397
まず、俺氏が天才。
- 399 :
- またこいつか
- 400 :
- それはフレームワークとは言わない
静的HTMLと言う
- 401 :
- 未だにPHP5系使ってそう
- 402 :
- 必ず炎上するフレイムワーク
- 403 :
- >>396
俺も使いたいからソース公開してや
- 404 :
- そーしてかがやくウルトラソウル と
そーして炎上フレイムワーク って
似てるよね
- 405 :
- >>397
まずセキュリティが最強。
アメリカ国防総省のチェックに合格している。
そして誰が実装してもファットコントローラにならないように組まれている
- 406 :
- コントローラー以外がファットになるんでしょう?
- 407 :
- 流石に妄言もここまでくると病気だな
- 408 :
- >>405が本当なら超勝ち組だし格下相手に粘着なんてする必要ない
ついでに愚民の書いたクソコードをメンテするようなクソ案件を受けなくても仕事に困ることもないだろう
ここに粘着している事自体が全てが嘘であることを物語ってる
- 409 :
- アメリカ国防総省のチェックwww
なんで秒でバレる嘘書いたしwww
- 410 :
- ネタとしても中途半端だし面白くないのが残念
やるならオレオレフレームワークって名前でGitHubに上げてる人みたいなことしてほしい
- 411 :
- 気を付けろ、ここも監視されてるぞ
- 412 :
- >>405 は俺じゃないけどな。
言ってることは間違ってない。
だが、そんなレベルではない。
もはや、神の領域に到達しようとしている。
- 413 :
- 一人で書いたのかな?
だったらスゲーよ!
早く公開してLaravel転覆させてくれや
- 414 :
- 一人で書いているよ。書き始めたのはもう5年も前になる。
気が向いた時などに少しずつリファクタリングを繰り返して、今となっては一番最初のコードからかなりの変貌を遂げたが、
基本的な考え方は何も変わっていない。
実装者が特別意識しなくても
・コードを肥大化させない
・コードを複雑化させない
・コードを重複させない
・コードを整頓させる
・コードの記述量を減らす
・セキュリティが担保される
・デザイナとの分業を可能にする
・本来頭を使うべきビジネスそのものにフォーカスできるようにする
もはや、これは神の手だ。
- 415 :
- 当初の思想から変わったことというと、
PHP 5.3以上をサポートして間口を広げる事を考えていたのを
今現在、PHP 7.3のフル機能をサポートするように書き換えている。
- 416 :
- >>414
Lavelだとこう書くけどオレオレフレームワークだとこう書けるという
例を見せてください
- 417 :
- >>414
まだLaravelのほうが上だな
- 418 :
- >>417
おまえのような下賤のものは、ずっとLaravelのような低級フレームワークをつかっておればよい。
- 419 :
- >>414
最高のフレームワークです。
はっきり言ってこのスレの誰よりもレベルが高い
- 420 :
- 自作フレームワークの話は他でやれよ
- 421 :
- >>416
>Lavelだとこう書くけどオレオレフレームワークだとこう書けるという 例を見せてください
俺氏のフレームワークは、基本的に、「書かない」。
もう、次元が違う。
- 422 :
- 一生懸命書くのは、フロントエンジニアさんだけ。
- 423 :
- >>414
もちろんバージョンが変わっても互換性は保っているんだろうな
- 424 :
- >>420
おまえが、ものすごく惨めで哀れな原人に見えるよ。
- 425 :
- >>422
それアンチパターンじゃねぇかw
- 426 :
- 自作フレームワーク使うぐらいなら普通に公開されているフレームワーク選ぶでしょ。
情報量や脆弱性が発見されたときの対応速度が段違い。
某フレームワークは脆弱性発見されて5分で修正パッチ来たからな。
- 427 :
- >>425
ゴミクズしか見たことが無いおまえがそう思うのも、無理はなかろう。
- 428 :
- >>426
ねぼけてるなぁ…。
オープンソースのフレームワークだから、極めて危険な脆弱性が発見されるのだよ。
- 429 :
- 変なの住み着いちゃったな
- 430 :
- フレームワークの評価の半分は基本機能、もう半分はエコシステム。
オレオレな時点でフレームワークとしての評価は半減だぞw
- 431 :
- >>430
うむ、おまえはLaravelのような低級フレームワークを使っていたまえ。
- 432 :
- >>430
お前たちが人生の貴重な時間をどれほど無駄に浪費しようとも
俺氏は一向に構わない。
- 433 :
- だれか>>421にツッコメよw
- 434 :
- ちなみに実際に使われて稼動してるサイトってどれくらいあるのかしら?
まさか、自分のブログサイトでしか使われてないとか…?
- 435 :
- >>414
お前が自作フレームワークに名付けた恥ずかしい
フレームワーク名晒せ
- 436 :
- >>428
それだったらWindowsは無敵のはずだが・・・・
- 437 :
- Laravelと関係ないなら他スレでやってくれませんか。
- 438 :
- >>434
黙ってろカス
- 439 :
- 大した話題もないし過疎ってるし別にええやん
変な転校生がやって来たみたいな空気よ
- 440 :
- >>435
つ「God Hand」
- 441 :
- >>440
面白いw
- 442 :
- 言っとくけど、嘘だからな。
もっと、まともな名前がついてるからな。
- 443 :
- >>442
真名を晒そうず
- 444 :
- >>443
3年待て。
- 445 :
- >>425
フロント比重なんて今なら当然だけどそれをアンチパターンとかおじいちゃんかよ!
- 446 :
- ひとりで開発するならオレオレフレームワークが最強なのは間違いない。
複数人ならエコシステムがある公開フレームワークにしとけ。
- 447 :
- >>445
最近GoogleとFacebookがその方式をアンチパターンと提唱しているらしい
- 448 :
- らしいじゃなくて記事とかソースくれよ〜
- 449 :
- おまえらは本当にバカばっかだな。
WEBアプリケーションの実装について極限までつきつめていくと、
結局、フロントの実装だけが残る。
サーバサイドがやるべき事は中朝化すると本当に簡単なコードに収まってしまい、
90%は自動生成できるレベルになる。
だが、フロントはそうは行かない。
フロントこそがアプリケーションに求められている事の本質であって、
そこをいかに効率化するかがアプリケーションの品質に直結する。
俺氏のフレームワークは、そこに全力で注力する事を可能にしているのだよ。
- 450 :
- いっておくが、中国・朝鮮化しろと言っているのではないぞ。
高度に抽象化するとどうなるのかを語っている。
- 451 :
- Laravelフレームワーク以外の話は他でやってくれませんか
- 452 :
- Laravelのほうが何もかも上だな
- 453 :
- Laravelスレの愚民どもは ID:0b9A11Fo様のお話をちゃんと聞けよ
そしてその小さい脳みそにありがたいお話を叩き込むんだな
- 454 :
- あほか
「俺氏フレームワーク」のスレ建てろよ
そんなこともわからない、できない低レベルで何を言ってんだ
- 455 :
- Laravelのほうが何もかも低レベルだ。
- 456 :
- で、フロントは何で作ってんの?jQueryとか言わないよな?
- 457 :
- もちろん、jQueryだ。
バカは全くjQueryの正しい使い方を理解していないのでやたら毛嫌いするが、
正しい使い方をした場合のjQueryの性能は凄まじい。
jQuery程、使う人間次第で黄金にも鉄くずにもなるライブラリは珍しい。
実際、ゴミクズのようなjQueryの山を見てきたせいで、
俺氏は、正しいjQueryの使い方を見つけ出せた。
シングルページアプリケーションのようにデータバインディングが極度に効率的な場合を覗いて、
jQueryは明らかに銀の弾丸だ。
だが、愚民どもはそれが銀の弾丸である事を理解せずに打ち込む。
銀の弾丸は、東洋の化物に打ち込んでも効果は得られない。
- 458 :
- 5年ほど前には、AngulerJSがやたら流行った。
Angulerを使えない奴はエンジニア失格とされる空気すらあった。
俺氏も当然使ってみたが、あまりのオナニー臭に「こんなもの流行るわけがない」と一蹴した。
今現在、Angulerはどうなっている?
俺氏が当時注目したのはVue.jsの初期バージョンだった。
当時からVue.jsは「フロント実装者のめんどくさいことを担保する」という事に特化していた。
センスが感じられた。
現在、Vue.jsはどうなっている?
俺氏の審美眼はおまえたちに比して群を抜いている。
俺氏の目は、常に真実だけを見抜く。
その俺氏が言うのだから間違いない。
jQueryは、正しい使い方をすれば最強の武器の一つだ。
- 459 :
- 今現在有るjQuery排除運動は、ほぼ、無駄に終わる。
jQueryの導入率70%超という実績もそうであるが、
事実、jQueryの簡便さと有効さは、他に類を見ない。
バカな奴がしたバカな実装を見て「jQueryは使えない」という判断は、
その判断を下した本人がそもそもバカである事を証明する結果となる。
- 460 :
- 結局フロントでファットコントローラーを書くわけな
- 461 :
- バカがjQueryを使うと、ファットになるな。
おまえの言っている事は、正しいし、間違っている。
- 462 :
- 世の中の愚民どものバカさ加減には、ほとほと辟易する。
- 463 :
- 俺氏のフレームワークは、フロントのコード量の低減にまでサポートする。
- 464 :
- >>458
AngularJSは携帯電話業界では一番ホットだよ。
AngularJSが一番モバイル対応が進んでいるので
モバイルアプリ用のフロントエンドによく使用される
- 465 :
- 俺みたいなJavaScript無効化したブラウザ使用している
アホみたいな業界だとGod Hand Frameworkはどうするつもりなの?
- 466 :
- jQuery使うぐらいだったらVue使う
- 467 :
- >>464
ガラパゴス化して生き残って、何になる?
>>465
JSを使わなければいい。
俺氏が提供するのはサポートであって、強制ではない。
- 468 :
- >>464
わかる。VueやjQueryやReactだと携帯電話によって
タッチイベントの挙動がかなり変わることあるけど
AngularJSだとどの端末でも同じ挙動で動作するな。
- 469 :
- >>466
使いたければ使えばいい。
俺氏が提供するのはサポートであって、強制ではない。
ただ、お前程度に必要なのはjQueryで充分事足りるはずだ。
- 470 :
- AngularJSはAndroid開発元のGoogleが管理しているだけあって
携帯電話に糞強いんだろう
- 471 :
- vue-cliやnuxtの開発速度を味わってしまうとjQueryとか他の
JavaScriptにはもどれないのおおおおおおおおおおおおおお
- 472 :
- Laravel+vueでよくあるサイトの管理画面さくっと作りたいんだけどおすすめのテンプレある?
- 473 :
- CakePHPのスレにも同じ人が現れているので
注意してください
- 474 :
- >>464
Angular"JS"とか言ってる時点で…
- 475 :
- Laravel単体だとほんとなんの話題もないし、
こんなオモチャがたまに現れるのは良いかもな
ただ毎日とかはキツいから勘弁してくれ
- 476 :
- Laravel+React+Redux+ReactRouter+MaterialUIで
認証機構の
Login
Register
PasswordReset
MailVerify
をSPA/MaterialDesignに作り変えたの作ったけど
配布する場合gitに置けばいいんかな?
- 477 :
- Packagistに登録
- 478 :
- Cakeスレにも出張しててワロタ
- 479 :
- >>449
早くgithubにでも公開してくれよ
まさか公開出来ないもの持って喧嘩売りに来てるわけじゃないよな?
- 480 :
- >>478
ちなみに、上げてない事から分かるとおり、あれは俺じゃないけどな。
- 481 :
- >>479
3年待て。
俺氏の作品くらいになると、安易に「出来たから公開します」というわけには行かない。
考慮しなければならない事が山ほどある。
おまえたちのような凡人は自由にコードを公開できて、実にうらやましい限りだ。
- 482 :
- 公開できないものはないのと等しい
結局イチャモン付けにここにきてるだけじゃないか
自分の作ったものがそんなに素晴らしいというなら下位のものにイチイチ構う必要ないだろ
- 483 :
- >>458
本当に設計力がある奴ならReactが一番向いてるんだけどなぁ
なんでその二つを選んじゃったんだか…
- 484 :
- >>483
教えてやろう。Reactは使った事が無いからだ。
どうも触手が伸びない。ダメだ、と言っているわけではなく、魅力が感じられない。
- 485 :
- ちっ、下がってしまった。
>>484 は、間違いなく俺氏だ。
- 486 :
- >>482
おまえは早漏なのか? 3年待てと言っているだろう。
公開するための障壁をとりのぞくのに、少なく見積もってあと3年は必要だと言っている。
その頃にはまさしく、神の手になっているはずだ。
- 487 :
- >>485
もしjQueryがこの世から消滅したら代わりにどのJavaScript
を選択する?
- 488 :
- 自作フレームワークスレあるみたいだからここでやれよ
https://medaka.2ch.sc/test/read.cgi/php/1558738149/
- 489 :
- >>474
AngularとAngularJSは別々に存在するぞ
- 490 :
- >>464
三年前にメインストリームから外れたものを今一番ホットとか言ってる矛盾に対して
- 491 :
- おっと490のアンカは>>489
- 492 :
- Laravel+vueでよくあるサイトの管理画面さくっと作りたいんだけどおすすめのテンプレある?
- 493 :
- >>490
この間のGoogleIOでまたメインストリームに載せるつもりだと
発表したぞ
- 494 :
- >>493
Angular2系があるのに未だにAngularJS使ってる奴ってPHP5系とかIE使ってる様なもんだろ
- 495 :
- 仮にAngularが縛りがあるのであれば
クライアントが古いブラウザ使っていたらAngularJS使うしかないな
- 496 :
- 僕の業界のクライアントはWindows2000ちゃん!!
- 497 :
- JRの新幹線時刻案内システムはWindows2000だから
貴様JR相手に仕事してるな
- 498 :
- イントラシステムじゃないグローバルなオンラインシステムな限りはもうサポートの切れたVista以前またはIE10以前を想定する必要はないんじゃないかと思ってるんだが
グローバル系で未だにそれらを考慮なんてするもんなのか?
- 499 :
- >>487
今のままでは絶対にしないから、そんな事を語っても無意味だ。
今のままで、Wordpressがこの世からなくなると思うか?
おまえは、生物の進化の歴史に何を学んだ?
先カンブリア代に絶大な栄華を誇ったアノマロカリスは途絶え、
当時最弱であったピカイアの子孫が現在地上を闊歩しているのだぞ。
圧倒的なまでに数を増やした物は
他を含めた全体が致命的に傷つくまで滅びない。
世の中というのはそういうものだ。
Wordpressが滅びないのならPHPは絶対に滅びない。
PHPは最強の言語だ。
PHPは8でJITコンパイラまで身につけようとしている。
まったくもって恐ろしい言語だ。
- 500 :
- >>498
俺の会社だと入札がメインなんだけど、
未だに入札の仕様とかにIE6で動作することとかいう要件あるから
過去のブラウザから逃れられない運命にある
- 501 :
- オラクルがJavaScriptに興味持っているみたいだから心配。
あいつらがjQueryとか手出したら破壊される
- 502 :
- >>500
入札というと、官公庁相手の話か?
>仕様とかにIE6で動作することとかいう要件あるから
Microsoftがセキュリティについて警告を行っている物をつくらせるのは、
明らかに公共の利益を阻害するので
事を公にして糾弾した方がいいぞ。
- 503 :
- >>502
図書館業界です
- 504 :
- 俺は官公庁相手の入札やってるけどやっぱりIE6で動作する要件
入る場合もあるね
- 505 :
- JRですらIE7で動作するシステムいるからなぁ・・・・
- 506 :
- 俺の業界はWindowsXP+IE6で動作しているシステムいるぞ。
さすがに外部のインターネットにはつながっていなくて
閉じられたネットワーク内で動作しているけど
システムが大規模すぎてリプレイスもそう簡単にはできない
- 507 :
- 俺の業界は他社の機器を使って動作しているけど、
その機器がWindowsXPにしかないAPI使って動作しているから
XPから変えられない
- 508 :
- うちの業界はブラウザによる縛りはないな。
ただ、入札仕様で「製品に使用するライブラリなどのサポート期限が
〇〇年以上あること」等が条件に来るので
入札をとる時期によって使えるライブラリが変わるのが困る
- 509 :
- >>503
図書館か。
これはまた、分厚い牛乳瓶の底のようなメガネをかけた生まれてこの方未使用の蜘蛛の巣が
張った菱餅を後生大事にしている活字を愛し活字に愛され活字で濡れる婦女子が
意味もわからずに恐怖と安寧の名の下に羊皮紙に血でしたためたような要求仕様であるな。
- 510 :
- >>500
それって専用線的なやつで一般には解放されてないやつじゃなくて?
- 511 :
- もはやララァ関係ないやん
- 512 :
- IE11のシェアが日本で未だに一定層あるのは
馬鹿がIE11に対応してるからだろう
ユーザーが悪いのではなく請負う奴らが自分で自分の首絞めている
- 513 :
- MicrosoftがChromeベースのブラウザ作るらしいけど
官公庁どうするんだろう?
e-taxとかいまだにIEでしか動かないシステム多いよね
- 514 :
- e-taxは、設計からなんとかしろよ。
何だよ、あのクソUIは。
- 515 :
- 今なら
「ラクテンスーパーポイントスクリーン」
登録するだけでRポイント150pが貰える!
※Androidアプリのみ
iPhoneユーザーはWeb版から登録のみ可能
登録完了後に表示される招待コ一ドをお持ちですか?のところで
「i9WPjs」
を入力する
完了
祭りだ♪ヽ('∀')メ('∀')メ('∀')ノワッショイ
- 516 :
- cake4も1.2の時みたいに難産バージョンになってるな
去年の頭に出すって言ってたけど1年以上延びちゃった
3.6で最後の予定が3.7、3.8と来てズルズルと…
- 517 :
- LaraveでMySQLCluster使えますか?
方法教えて欲しいです。
- 518 :
- >>517
プログラミング言語は3306番のポートにアクセスするだけなんだから
クラスタはMySQLの中で設定する事であって
MySQLでクラスタやる方法を調べればいいだろ
- 519 :
- cakeもういらねーだろ
日本人しかつかってないじゃん
数年前のFuelphpと同じだ
近いうちにcakeは死ぬ
- 520 :
- >>517
素晴らしい質問だなぁ…
こんな人がなぜMySQLクラスタ使おうとするのか不思議でならない
- 521 :
- codeIgniterが重くて苦痛
cakeみたいにユルユルすぎて軽いフレームワークは大人気
というか世界中で使われてるし
なぜか日本だけジジイどもが使ってない
- 522 :
- >>521
ここcodeIgniterスレでもcakeスレでもないんだけど結局ここで何を主張したいのさ?
- 523 :
- >>522
お前が言うな
- 524 :
- >>520
MySQLクラスタが評判悪いということでしょうか?
- 525 :
- >>523
>>521読んだだけじゃLaravelを肯定的に捉えてるのか否定的に捉えてるのか判断難しいじゃん?
- 526 :
- Laravelのおすすめの書籍教えてください
できれば英語で
- 527 :
- >>526
A PHP framework written by Tsuyano Shouda, a book called Laravel introductory is recommended.
- 528 :
- そういう意味じゃないです・・・・
- 529 :
- >>526
書籍じゃないけど
https://laracasts.com/series/laravel-from-scratch-2018
- 530 :
- 無難にこれでいいんじゃない?メニューは左上クリック
https://readouble.com/laravel/5.8/en/installation.html
- 531 :
- >>526
Matt Stauffer
Laravel: Up & Running: A Framework for Building Modern PHP Apps
- 532 :
- 公式のドキュメントって全然詳しくないよね、役に立たん
- 533 :
- でも一番正しいよね
- 534 :
- んなことはない
- 535 :
- そうでもない
- 536 :
- >>245
そんなしょうもない事に労力使ってたんか
そんな事してるからリィンさんは不殺の剣聖様でロボット乗りながら教師をする宰相の息子で生真面目なのに
教え子のパンツを覗きながら他の女にも手を出しまくりクロウ他の男にも色目を使う極彩色の変態になったのか
続きモノのギャルゲにしなけりゃこんなキ○ガイめいた主人公にならずに済んだのに
- 537 :
- なんだこいつ
- 538 :
- >>537
誤爆だって言っただろ
- 539 :
- >>538
この>>536の後には「誤爆しました」というレスはない。
お前「誤爆しました」というレスもまたどっかに誤爆してると思うぞ
- 540 :
- jQueryで
<div class="foo">
<pre data-lang="plain">hello world</pre>
</div>
$('.foo').after('<button />').on('click', function(){
const $pre = $(this).find('pre')[0]; // ←多分間違ってる
console.log($pre.text());
console.log($pre.data('lang'));
});
みたいなことをvueでスムーズにやる方法って無いかな?
$slot使えと書いてあるけど、階層とかが複雑だとchildrenとか入れなきゃならないのが
面倒なんだが。
- 541 :
- Laravelでvueを使用した場合
vue.js って後からコンポーネントのロードとかできんの?
一通り日本語ドキュメント読んでみたんだけど出来なさそうなんだよなぁ。
例えばテンプレートのHTMLとかコンポーネントのソースは全部独立した別ファイルにしておいて、
あるボタンをクリックしたら必要なテンプレートとコンポーネントのファイルを読み込んで、
ノードもその時その時でDOMに追加してコンポーネントをインスタンス化するみたいな動き。
どうも new Vue({...}) ってやる前に必要なコンポーネントは使う使わないに関係なく全部読み込んでおかなきゃいけなくて、
コンポーネントの配置元になるバーチャルノードも最初から記述しておかないと機能しないっぽいんだけど、
俺の理解不足?
描画を100%JavaScriptに任せたくて、body タグは空の状態から始めたいんだけどいきなり躓いてる。。。
こういうのって vue.js じゃなくて Angular.js でやるべきなのかな?
- 542 :
- >>539
すまん。
ハローキティスレに誤爆してたわ
- 543 :
- >>541
<body>でなくて
直下に<div#app>とか置いてこいつに枝生やしてったら?
知らんけど
- 544 :
- キティちゃんのスレって何したら閲覧しようと思うんだよwwwww
- 545 :
- >>541
AngularはAngular
jsが付いてるのは過去の遺物
- 546 :
- >>545
AngularじゃなくてAngular.jsを使いたいんです
- 547 :
- >>541
AngularはAngular
jsが付いてるのは過去の遺物
- 548 :
- Angularおじさん怖い・・・・
- 549 :
- python3よりphp7のほうがはえーのに
何でlaravelよりdjangoのほうが早いわけ?
- 550 :
- Laravelがほとんどの処理がPHPなのに対し
djangoはCネイティブ処理が多いからかな
- 551 :
- DjangoにJITのモジュールがあるとかっていってなかったっけ?
- 552 :
- >>551
俺そんなこといっていないよ
- 553 :
- >>550
へーしらんかった
ありがとー
- 554 :
- >>550
ありがとう
- 555 :
- Rubyも昨年末2.6でJIT入ったけどPHP来年のVer.8までおあずけなんだよなぁ
- 556 :
- RubyにJIT入るってすごいちごおいしい
PHPはよJIT入れろや
- 557 :
- 「いちごおいしい」
この部分について釈明を求む
というか俺にもくれ
- 558 :
- PHPだと1リクエストごとにFWの初期化処理を行っているのが遅い理由でしょ
特にLaravelは読み込むファイルも多いし重い
他の言語だとアプリケーションサーバ起動時に一回だけ初期化処理をするので1リクエストあたりの処理が少ない
PHPでもSwooleやReactPHPなどを使えば同じことはできるけど、まあ既存のFWを乗っけてもバグりやすいだろうね
- 559 :
- >>558
遅いって、どのぐらい時間がかかってる事を言っている?
- 560 :
- >>558
プロダクト版はキャッシュ効いてるんじゃないの?
- 561 :
- >>559
数百マイクロ秒単位
- 562 :
- >>561
単位、ミリじゃないか?
- 563 :
- 結構Java嫌いな人多いんだね。自分もJavaは好きじゃないけど。
>>440
Javaが検討される規模のWEBサービス作る時にJVM以外の選択肢って例えば何かあるのかな?
>>441
Javaの出始めと比べたら劇的に進化してSunの言う通りになったと思うけどな。
Java離脱組もパフォーマンスじゃなくて開発効率やサービスの拡張性を気にしてる。
>>446
少数派なのはそうなんだけど、依頼側から見たサーバーサイドkotlinのデメリットは
・現状では開発者が少ない=人が集まらないことによる遅延、開発者単価
・実績がない=未知の何かが起こるかも
なのでローンチ出来てる時点でデメリットは乗り越えているし、
Android界隈では確固たる位置にいるからこの先メンテ人材が見つからない心配もない。(←ここが流行に左右されて困るポイント)
悪くない選択だったと思うんだけど
- 564 :
- >>563
なんというかJavaって炎上案件多くない?
- 565 :
- >>564
ねえねえなんでそんな全員がわかっていることを今更とぼけようとするの?
ウザいから逃げ道塞いどくと「Java 炎上」とかで検索すればこの言語が
酷くて、構築後のシステムが炎上しやすいことが簡単に確認できるよね
そしてこのWebProgにくることができるあなたはそのことを当然知ってるよね
事実から逃げて誤魔化そうとするの見苦しいだけだからやめようよ
- 566 :
- ここPHPのLaravelスレだぞ
- 567 :
- 実際、JavaとPHPってどっちが炎上案件多いんだろう
- 568 :
- >>567
PHPはいざとなれば部分毎に全取っ替えしていけばなんとかなるけど
Javaは画面同士が疎結合とは限らないから面倒なんだよね
>>565
自分自身が関わったJava案件は殆どない(1〜2件くらい)から決めつけはできないかなって思っただけでやっぱ言語的な欠陥なのな
- 569 :
- Javaのほうが比較的案件規模も大きいし、母数も多いから炎上案件の絶対数は多いだろうな
- 570 :
- 加えて無駄に1プロジェクトの人数が無駄に多いからな
- 571 :
- 【速報】クオカード五百円分とすかいらーく優待券をすぐ貰える
https://pbs.twimg.com/media/D8H9ysyUIAAC3ro.jpg
@ スマホでたいむばんくを入手
A 会員登録を済ませる
B マイページへ移動する。
C 招待コード→招待コードを入力する [Rirz Tu](スペース抜き)
今なら更に4日18時までの登録で2倍の600円の紹介金を入手
クオカードとすかいらーく優待券を両方ゲットできます
数分でできますので是非お試し下さい。
- 572 :
- 銀行クラスのシステムだとJavaだよね。
PHPとか選ばれないし
- 573 :
- 言語で炎上するかどうか議論するのはやめてくれ。なんの関係もないから。
- 574 :
- いやもっと議論していいぞ。大事なことだから
- 575 :
- laravel使えば炎上はせんだろ
ただ速度問題あるからスケールしにくいんじゃね
- 576 :
- >>571
一応貰っておく
- 577 :
- 例のみずほのサグラダファミリアもPHP5.1という噂を聞いたけどマジなんかな
- 578 :
- mixでコンパイルしたcss内のfontawesomeの場所が/fonts以下で固定されてて、Laravelをサブディレクトリで動かした場合動作しない
いちいち手で../に置換してるんだが解決方法ないかな?StackOverflowに同じ質問あるけど有効回答がない
- 579 :
- なんかディレクトリ構成画像とかで頼む
- 580 :
- コンパイルした結果
public
├─css
│ └─app.css
├─fonts
│ └─vendor
│ └─@fortawesome
│ └─fontawesome-free
│ ├─webfa-brands-400.eot
│ └─他いろいろ
└─js
みたいになってて、app.css内に
@font-face {
font-family: "Font Awesome 5 Brands";
font-styleとかいろいろ
src: url(/fonts/vendor/@fortawesome/fontawesome-free/webfa-brands-400.eot?05783t5172ef1ac128c576bf88fac236);
}
みたいに書かれている。
LaravelのURLがドメイン直下ではなくサブディレクトリなので/fontsだとアクセスできない。../fontsにしないといけない。
そうするための設定方法がわからない。
- 581 :
- app.scssから読み込まれる_variable.scssに変数を定義すればなんとかならないか?
$icon-font-path : 'path/to/fonts/dir';
とかだと思うけど
- 582 :
- 結局PHPの最強フレームワークはLaravelという認識でよろしいか?
- 583 :
- 数字見て総合的に考えれば今のところはそうでしょ
盛者必衰だから3年後はどうなってるか分からんけど
- 584 :
- >>580
fonts自体.resource/scss内に置いてapp.scss内でそれをurl関数使わずに相対パスで@importできないか?
基本的にはよっぽどの事がない限りはpublicの中身は自分では編集しないのが望ましいな
- 585 :
- >>584
それだとデプロイ時にpublic以外を見せないといけなくならない?
- 586 :
- ゴメン584は普通に勘違いだった
public/fonts/any.ttf
とか置いたとして
resource/scss/app.scssに
@font-face {
font-family: 'example';
src: url('/fonts/any.ttf');
}
とか書いて
$ npm run dev
でやりゃ良さそう
- 587 :
- ブート中ではなく、ブート後のログインIDとパスワード入力中のタイミングで
systemctl start コマンドを実行する方法はありますか?
- 588 :
- 今から新規開発でcakeでやるとか言い出した某開発会社に付き合わされるハメになった
こっちが提案したLaravelは軽くスルー
クソジジイかと思ったら意外と若い奴だった
- 589 :
- PHPには数多のフレームワークが存在するけど
どういう案件がきたらお前らLaravelを選択しているの?
- 590 :
- >>587
もう少し他人に分かるように質問しろよ…
何のブート中? 何のログイン?
- 591 :
- よく優秀な人は技術問わずって方便垂れられるけど
本当に優秀なやつは働き口たくさんあるから
それはスキルセットではやりたくないのでと断れる立場だよな
- 592 :
- >>587
クライアントから通知ならWebSocketでサーバとのpubsub実装して
入力中にコマンド実行を飛ばす、とか
- 593 :
- >>587
解決策を見つけるにあたってはなぜそうする必要があるかの理由が重要だと思う
- 594 :
- 仮想コンソールの2番とかを login じゃなくて sh 動かしとくとか?
セキュリティ皆無だが。
- 595 :
- ほんと、なぜそんなことをしたいのかまったく分からんのだが、
エスパーの人に答えてほしい
- 596 :
- 皆さんは Google Drive のマウントってどうしてるの
- 597 :
- そんな事でマウント取ってどうすんの?
- 598 :
- php artisan serveで開発用サーバを動かしているのですが
このコマンドを実行しているとMySQLが起動に失敗してしまいます。
何故でしょうか?
- 599 :
- 今確認しましたが、
php artisan serve実行後、MySQLを起動→MySQL起動失敗
MySQLを起動後、php artisan serveを実行→両方とも起動成功
になるようです。
- 600 :
- 根幹から立ち上げてくのは基本なんで解決したのなら原因探るのは面倒なだけだなあ
大方Laravelが3306ポート握ってMySQLが起動失敗ってとこだと思う、それの確認作業は上記の通り
- 601 :
- >>600
それLaravelがじゃなくVagrantがとかだろ?どうせ
- 602 :
- 定期的に湧くよねMySQLがどうの言うヤツ
これVagrantだったの?
- 603 :
- cakeからの移行を考えて検討しているんですが、公開フォルダにサブディレクトリ作ってソースを置けばすぐ動くのに慣れていて、ドキュメントルートを設定しなくちゃいけないとか面倒くさくてやってられないです。
開発環境とかで複数プロジェクト同時進行の場合とか、プロジェクトが増えるたびに皆さんWebサーバの設定を増やしていってるんでしょうか?
- 604 :
- バーチャルホストの設定ファイル1個追加で置くだけやん
むしろこっちの方が楽だと思うが…
- 605 :
- laradock卒業しました
- 606 :
- すみません、ソース管理で質問です。
Laravelで開発したアプリをgitで管理する場合、vendorフォルダのファイルって管理に含めてますか?
vendorも管理に含めるとファイル数・サイズも大きくなり、tortoisegitを使うのが厳しい状態です。
「composerで配布されるコンポーネントは下位互換性が保証される」という理想が守られるなら
vendorは管理から外してもいいのですけど、そうもいかないですよね?
みなさんどうしてます?
- 607 :
- venderとnode_modulesとstorageとbootstrapくらいは管理外にしていいんじゃない?
- 608 :
- むしろ含めちゃいかんよ
何のためのcomposer.lockファイルだ
- 609 :
- >>606
除外するよ。lockファイルがバージョンを固定するためのファイルなので追加しといて。
- 610 :
- MySQLについて質問したものです。
MySQLを起動後、php artisan serveを実行→両方とも起動成功
と書いていたのですが5分後にMySQLがダウンし
10分後ぐらいにartisan serveも終了してしまうことがわかりました。
もはや良くわからないです・・・
- 611 :
- >>610
artisan serveがダウンしたときコンソールにエラーはでる?
- 612 :
- エラーは出ていないです。
自分が知らず知らずに終了してしまった可能性を考慮し
キーボードを一切触らないで待機していても勝手に終了してしまいます。
- 613 :
- もしかするとえらーひょう
- 614 :
- MySQL側のログには何か残ってないの?
- 615 :
- >>610
OSは?
- 616 :
- >>606
全部含めてるよ。リポジトリから一式落とした状態で動かんと意味がないでしょ
このフォルダだけ別の所から持ってくるとかやるのか?そんなの動作保証できない
composerも完璧じゃないからな、よくコケるし
- 617 :
- 含める場合はサブモジュールにするかな
プロジェクトリポジトリの履歴汚染と肥大化を防ぐ為に
- 618 :
- >>615
Gentooです
- 619 :
- composerよくコケるか?
少なくともここ3年くらいはまったく起きてないな
- 620 :
- 導入時にトラブったことはあるが、普通に使えていれば特に問題ないな
- 621 :
- 少なくとも本番環境でcomposer install直接叩くことはないし、
開発環境やステージング環境でしっかり検証できればいいのだから
リポジトリに全部含めるのはただgit依存に変わるだけだし個人的には無駄にしか思えない
- 622 :
- composerもnpmもRubyGemsもネイティブモジュールがあるからリポジトリには入れないよ。MacでビルドしたらLinuxで動かないから。リリース前に本番と同じ環境でビルドする。
- 623 :
- >>621
composer install実行しないってその場合ネィティブモジュールとかどうするの?
- 624 :
- ステージング環境からrsyncとかでいけるでしょ
そのために環境合わせるわけだし
- 625 :
- >>618
原因それじゃね?
- 626 :
- >>624
ローカルでmac/win/linuxで開発してる人が混在してたら困るやん。
- 627 :
- ごめん、勘違いしてた。本番リリースの話だったね。
- 628 :
- >>625
原因がGentooとのことなので
OSをArchLinuxに変えたところartisan serveでSegmentation Faltが発生するように
なってしまいました
- 629 :
- OSがって言うかね
依存関係がちゃんと解決できてないんじゃないかとね
Gentoo->ArchってチョイスするってそんなスペックきつきつなPCでやってるわけ?
それだったらもしかしてメモリ不足とかなんじゃない?
- 630 :
- oomキラーで殺されてるのか?
/var/log/messages 見てみれば?
- 631 :
- なんでそんなディストロ使ってるの?
Linuxユーザーの実態
http://i.imgur.com/qgLh1fT.jpg
Linuxユーザーの人生の流れ
https://pbs.twimg.com/media/CQsgpyuU8AAM5H5.jpg
スレの意見をまとめるとこんな感じか?
https://i.imgur.com/Jt1utoG.png
- 632 :
- オタクだからに決まってんだろ。硬派な奴はGentooかArchなんだよ。
- 633 :
- 趣味でphpは書きたくないなぁ
- 634 :
- 趣味でやりたくないもんを仕事で書くほうが嫌な気もするけど🤔
- 635 :
- むしろ趣味の方が一から言語の最新仕様で好き勝手出来るから好き
- 636 :
- LaravelでPostgreSQLを使おうと思うのですが
何か注意点はありますか?
- 637 :
- ありません
- 638 :
- >>593
dhcpcd を使ってネットに接続しています。
ログイン後にすぐネットを使いたいので、systemctl enable しているのですが、
wifi に接続して IP を得るのに時間がかかる場合が時々あります(15~20秒ほど)。
systemctl enable した他のサービスはすぐ起動するのですが、dhcpcd だけ遅いので、
今はこれがブート速度のボトルネックになっています。
もしログイン画面と同時に dhcpcd の起動プロセスが開始されれば、
IDとパスワードを入力し、startx コマンドを実行し、
ターミナルを開いて一呼吸置くころには、
たいてい完了しているだろうと考えました。
dhcpcd が時々遅い原因を探るのが本来やるべきことなのですが、
なかなか原因を特定できません。
作業開始が待たされなければ方法は何でも良いと割り切り、
今回質問の方法を模索し始めた次第です。
- 639 :
- Laravelと関係あるの?
- 640 :
- うん?ログインってOSのログイン?
Laravel全然関係ないぞ
- 641 :
- >>638
それ単純にそのPCを固定IPにしちゃえばよくない?
- 642 :
- >>640
Laravelのログインのことです
- 643 :
- 最近BASIC認証じゃなくてIPアドレスでセキュリティ担保したがるクライアント多い
うち固定IPないのに…
- 644 :
- 自宅auの光回線10年近く使ってるけどその間にIP換わったの1回だけだな
- 645 :
- au光は実質固定だよね
ドコモのは繋ぎ直す度に変わる
- 646 :
- VPS借りて固定IP割り当ててポートフォワードするかGMOBBで月1000円で契約してこい。
- 647 :
- >>640
日本語勉強しろ
Laravelのログインとか聞きたいことが意味不明過ぎる
だからだれも答えられない
- 648 :
- どこから固定IPの話になったのかと思ったら>>641の言ってる固定ってローカルIPの事じゃん
- 649 :
- >>638
なんや知らんけどこれじゃね?
dhcpcd@.service によって起動が遅くなる
https://wiki.archlinux.jp/index.php/Dhcpcd#dhcpcd.40.service_.E3.81.AB.E3.82.88.E3.81.A3.E3.81.A6.E8.B5.B7.E5.8B.95.E3.81.8C.E9.81.85.E3.81.8F.E3.81.AA.E3.82.8B
- 650 :
- 無難にCentOS7選んどきゃ困る事はそうないのにな
- 651 :
- >>647
LaravelのログインといったらLaravel-adminじゃないか?
- 652 :
- Laravel-adminにしても意味が分からんが…
systemctl叩くのになんでLaravel絡めようとするかがまったくもって意味不明
startxとか謎の要素も出してきてるし、どんな環境で何がどう稼動してるか分からんから
超能力者以外解答できないと思われ
- 653 :
- CockpitみたいなWEBベースのOS管理システムを
Laravelで作りたいんじゃないか?
- 654 :
- よっぽど持ち歩くノートPCとかじゃない限りDHCPでIP取得する必要はないだろ
- 655 :
- >>653
このレベルで躓いてたらできるまで100年かかるわw
- 656 :
- Laravelからsystemctl制御するライブラリがあったような気がする
- 657 :
- とりあえずその使いこなせてない専ブラ捨てろ
画像をビューアーで開くにあたって上限設定がかかってるんだろ
上限はずす処理するとかプラグイン入れるとか、
それが面倒だったり難しいなら普通にブラウザで開け
- 658 :
- Laravelはルートを全部書かなきゃいけなくて面倒というイメージがあるけど、慣れの問題?
- 659 :
- つ Route::prefix
- 660 :
- 初心者です、アドバイスください。
www.ritolab.com/entry/51
を見てmake:authで認証機能を作りました。
Userテーブルに10数個のカラムを追加するのは悪手でしょうか?
UserSetting等として作ったテーブルからUserIDを紐づけて参照するのが良いですか?
よろしくお願いいたします。
- 661 :
- >>660
好きにやればいいよ。おれは後者。
- 662 :
- 俺は前者
- 663 :
- わいも前者
- 664 :
- どっちもやったけど、結果どっちでもええと思た
- 665 :
- Laravelの仕様的にCakePHPよりバグり易そうな部分ってあるんかな?
- 666 :
- >>661
手間暇かけている努力が見えてるのがネタ抜きでパンツだけだから救いようがねぇ
で、社員や信者は必死にパンツを無かった事にしようとしているから余計哀れに見えてくる
- 667 :
- 最近Laravel関連でググると公式より日本語サイトが上位に出てきて邪魔でしょうがない
その都度uBlacklistに突っ込んでるけど
- 668 :
- ブラウザの言語設定変えればよいのでは?
- 669 :
- >>668
言語設定変えたら日本語出てこなくなるでしょ
- 670 :
- 検索時にlang:enでも付けとけよ
- 671 :
- ジャップの情報はレベル低いからな、見てるとアホになる
- 672 :
- composerでlaravelプロジェクトを作成するまでの手順の記事が
人気ランキング1位になっていたときは愕然とした。
ジャップw
- 673 :
- いかがでしたか?w
- 674 :
- 宮迫の闇営業の件で何をトチ狂ったか、宮迫が出演する番組のスポンサーが
Laravelだと勘違いして開発者達にお問い合わせメール送りまくってるの草。
Laravelと宮迫は関係ねーよw
- 675 :
- Laravelに、CakePHPのツール群入れたり、
その逆に、CakePHPに、Laravelのツール群を入れたような
フレームワークって無いの?
- 676 :
- >>675
ツール群ってかなりパッケージ化されてない?
Composer使えばどうでも良くない?
- 677 :
- LaravelにDebugKitが備われば光と闇が両方備わり最強に見える
- 678 :
- 仕事でdjango使うことになったからdjangoやってるわ
慣れてるlaravelがいいのに…
laravelのほうが断然ググってたら
整理された情報出てくるから楽だわ
英語日本語問わずね
結局フレームワークなんて使用感よりググって知りたいこと即手に入るかどうかじゃん
だるいわ…
- 679 :
- わーわーうるせえわ
- 680 :
- 仕事でdjango使うことになったからdjangoやってるのじゃ
慣れてるlaravelがいいのにのう…
laravelのほうが断然ググってたら
整理された情報出てくるから楽なのじゃ
英語日本語問わずにの
結局フレームワークなんて使用感よりググって知りたいこと即手に入るかどうかなのじゃ
世知辛いのじゃ…
- 681 :
- php 版の django が laravel だって言う人もいるけどな知らんけど
- 682 :
- 馬鹿でもコードが読める=王道フレームワーク
読む人によって挙動が変わる=丁寧な作りのフレームワーク
と著しい勘違いしてる低能連中が作ったフレームワーク、それがLaravelだ!
きっとCakeやSymfonyもどきも洗練された斬新なシステムと思い込んで作り込んだんだろう
奴らに皮肉は通用しない、徹底的に指差して嘲笑うくらいしてもLaravel開発者に通じるかどうかだ
奴らの鉄壁のアホ具合を舐めてはいけない
- 683 :
- PHPのバージョンをあげるので
Laravelも最新にしようと思ってますが
やっぱりバグだらけですか?
- 684 :
- やっぱりバグだらけ!
- 685 :
- 結構毛だらけネコ灰だらけ
Laravelやっぱりバグだらけってねぇ
- 686 :
- Cake、粗大ゴミじゃん
- 687 :
- 質問させてください。
composerでLaravelをインストールしました。
composer create-project laravel/laravel --prefer-dist laraveltest
を実行しました。
このlaraveltestがプロジェクト名になると思うのですが、
プロジェクトのディレクトリ内にLaravelのファイル一式がインストールされました。
フレームワークはプロジェクト毎にインストールするのでしょうか?
例えば1つのサーバにLavavelをインストールして、
各プロジェクト毎にLaravelを利用するという使い方はできないですか?
- 688 :
- 自分で魔改造すれば、何でもできるよ!
- 689 :
- >>682
ごめん、CakeもLaravelも最底辺のどんぐりの背比べだと思ってるんだけど、
おまえの論旨はどっちが優れているって言ってるの?
アホらしくてよくわかんない。
- 690 :
- >>687
vendorだけはシンボリックリンクを貼ればいけるかもしれない(※未検証)
node_modulesもいけるかもしれないけどフロントエンドはバージョンアップ頻繁だしちょっと怖い
- 691 :
- vendor共有したいってのは誰もが考えるところだよね
- 692 :
- 底辺の背比べで、結局cakeに戻ったわ。
チームで開発するならcakeのほうが品質高かったよ。
- 693 :
- レガシーサイト作っときゃいいって人ならそれでいいんじゃない?
- 694 :
- PHP自体がそろそろレガシーになりつつあるからなぁ
もう何使ってもドングリ比べじゃないのかね
せめてAWSのLambdaがPHP対応すればのぉ
GoogleもAzureも対応しなさそうだし
- 695 :
- でもPHPのLaravelは最強でしょ
- 696 :
- WordPress専用言語
- 697 :
- cakeよりは断然いいと思うが…
- 698 :
- >>697
その断然っていうのが体感できなかったのよ。
エンドユーザから見て、laravelシステムがcakeシステムより断然優れてるところって何?
laravelシステムじゃないと体感できないことって無くない?
- 699 :
- あ、別にcakeが良いと言ってるわけじゃないんだ。
長いものに巻かれたい自分としてはcakeからlaravelにシステムの刷新をしたいのだけど、エンドユーザ目線でしか考えない上司を説得するのに根拠が薄すぎて苦労してる。
キラーワードがあれば聞きたいなと。
- 700 :
- Laravel-Mix使ってないからやん
- 701 :
- は?ユーザー側に違いがわかるわけないだろ
- 702 :
- SPAやPWAにすればユーザーから見ても明らかに違うだろ
- 703 :
- どう違うの?
そんなのフロントの作り方次第じゃね?
- 704 :
- >>687
やめとけ。いまその構成はスタンダードじゃない。
- 705 :
- 生のwebpackは面倒すぎて吐きそうになる
- 706 :
- >>698
エンドユーザからすればLaravelであろうがCakeであろうが関係ない
というか判別つかんだろ
- 707 :
- 結局今のPHP界隈ではLaravelが最強
FuelPHPが最弱
- 708 :
- ・開戦前夜に全員でテーマパークで遊ぶなど緊迫感など微塵も無いお笑い戦争ごっこ
・ボス戦になるといちいち卒業式台詞リレーによるボスとの対話が始まりプレイヤーを萎えさせる
・プロセスが描けていないので全く何の感慨も起きない空零キャラとの白々しい邂逅シーン
今まで特に付き合いがあったわけでもないのに急にマブダチのようにお互いを認め合う
・イエス、ファウンダー()
・やっぱり生きていたあの人達、やっぱり生き返ったあの人達、やっぱりいい人だったあの人達etc.
全て予想通りなので何の感動もない
・無くても全然よかった鬼の力
・全くしょうもないキャラだったレクター君
・全く意味のないキャラだったクレアおばさん
・全く竜頭蛇尾に終わったオズボーンさん
・唐突に水泳やった以外に全く存在意義のなかったシャーリーさん
・ただ色んな勢力に声かけただけの何の捻りも無い総力戦だったミルミラージュ
・ギルバートレベルの姑息な手段で一人老女を殺った以外に存在感のなかったルーファスさん
・犯罪者やテロリストを平気で招く皇室の婚礼ってどうなの
・特に修練に励んでるわけでもないのに通信教育で皆伝だかを授かる流派ってどうなの
・1,2,3,4,5,6,7,8()
- 709 :
- Fuelの書籍は良かったのに残念だ
- 710 :
- fuelの書籍のおかげでMVCにスムーズに入れた
- 711 :
- お前らが今まで見てきたLaravel使ったクソコードってどんなの?
- 712 :
- Laravelも糞だが、
FuelPHPにときめいた奴はそもそも、整形美人に騙される童貞だと
7年前から思っていた。
- 713 :
- Laravel-admin初めて使って便利だと思ったのですが
admin:makeのようにモデルからコントローラーとフォームを自動生成する機能を
自分のプロジェクトでも使うことはできますか?
- 714 :
- LaravelにCakePHPをインストールしてみたのですが
上手く動きませんでした。何か方法があるのでしょうか?
Googleがこの間の公園でLaravelにCakePHPをインストールして
システマティックムササビを作るデモやっていたそうなので
自分も試したいと思ってチャレンジしています
- 715 :
- すみません。誤字修正します。
公園→講演
システマティックムササビ→システム
- 716 :
- お前にとってLaravelってOSかなんかなの?
- 717 :
- Googleがこの間の公園でLaravelにCakePHPをインストールして
↑どういう状況かちょっと想像してみるか…
- 718 :
- 同名のファイルが上書きされてバージョン変わったり、最悪別物になっちゃってたり?
- 719 :
- 俺がLaravelだったようですに迫る勢いだな
- 720 :
- システマティックムササビ
↑これもちょっと想像してみるか…
- 721 :
- 最後のLaravel天衝、それは・・・俺自身が、Laravelになる事だ ...
みたいな?
- 722 :
- 代償としてプログラマの力が失われる
- 723 :
- laradockとかで環境作って、無理くりcake入れるって事?
- 724 :
- cake入れられるんだったらsymfonyも入れられそう
- 725 :
- FW合体
- 726 :
- LaravelでMySQLを使用するとぶちぶち接続が切れるんですが原因わかりますか?
Mariadbだと接続は安定しており切断は一回もなかったです。
また、接続はlocalhostに対して行っているので外部ネットワークの影響もなさそうです
- 727 :
- 接続が切れるって意味が分からん
基本的に常に繋がってるものではないよ
とにかく接続エラーとかならクライアントが吐き出してるエラーログとか見て原因つかめ
- 728 :
- そんな無駄なことやってる暇あるならフロントフレームワークの一つでも習得した方がよっぽど有意義じゃないか?
- 729 :
- >>726
OSとWebサーバー何使ってるのかいい加減書いたらどうだ?
- 730 :
- FireBaseでいいじゃん
- 731 :
- >>729
OSはUbuntuでWebサーバはApacheです
- 732 :
- サーバー側のログは?
クライアント側のエラーメッセージは?
そんな情報だけで原因答えられる人がいたら超能力者だからさぁ…
- 733 :
- でドキュメントルートに
composer install laravel/laravel pref-dist
でプロジェクトインストールしてんの?
- 734 :
- 間違えた
composer create-project --prefer-dist laravel/laravel PROJECT_NAME
だった
- 735 :
- >>726
そんなサーバ捨ててしまえ
- 736 :
- Laravelっていうのがよくわからん
教えて
- 737 :
- 有り体に言えばシェフの気まぐれサラダって感じかな
- 738 :
- アニメ版ひぐらしのなく頃に解のEDを歌ってたボーカルだよ
- 739 :
- EBライブラリってのをdownloadしてcompileしてみた。
http://www.mistys-internet.website/eb/
ドキドキしながらsamplesを動かすと、動いてるみたい。
このライブラリを使えばEPWING辞書データにアクセスする事ができる。
俺の場合、手元のジーニアス大辞典にアクセスできた。
こいつでLaravelアプリ、辞書Viewer作れば需要あるかな?
EPWINGだけでなく、辞郎形式のテキストにも対応しちゃう事にする。
Qiitaへ投稿されたMouse Dictionaryみたいなのを目指すけど、需要あるか、ちょいと心配。
- 740 :
- 間違いなく需要はない
- 741 :
- この間githubの統計情報を見てびっくりしたんだけど
githubに上がっているLaravelプログラムの52%がフランケンシュタインが作っていて
30%がアメリカが作っているらしい
- 742 :
- すみません。誤変換です。
正しくはフランス語です
- 743 :
- すみません。また誤変換です
フランス語ではなくフランスです
- 744 :
- フランケンシュタインすげー
- 745 :
- 18%はオオカミ男かな?
- 746 :
- あれから施行錯誤しているのですがやはりMySQLの接続が安定しないです。
DB接続エラーになっているのですが原因がわかりません。
MySQLサービスを止めた場合はもちろんアプリケーションログなどに接続エラーが
出るのですが、MySQLサービス起動済みの状態で接続エラーが発生した場合は
何故かアプリケーションログにエラーが表示されないです。
- 747 :
- >>746
ねぇcomposerでちゃんとインストールした?
DockerとかVagrantとか余計なもん使ってない?
- 748 :
- >>747
素のUbuntu18.04を使用しております
- 749 :
- selinux無効にしてる?
- 750 :
- プロジェクト作成時はLaravelコマンドを使用しました
- 751 :
- 今通信のパケットキャプチャをして気づいたのですが、
接続エラーになるときはMySQLからMySQLの通信プロトコル仕様書に載っていない
不正な電文が送られてきていることがわかりました。
どうやらMySQLに問題がありそうなのでMySQLスレで聞いてみます。
皆様ありがとうございました
- 752 :
- クライアントとサーバーの怪しいログをそのまま転記しろ
超能力者現れるまで待つつもりか?
- 753 :
- てかちゃんとMariaDB10.3か10.4使ってる?
それ以前のバージョンだと
varchar型でutf8mb4で255文字の型が767byte超えて使えない不具合みたいなのがあるの思い出したけど
- 754 :
- >>726でMariadbだとうまくいくって言ってるから
今はMySQLを使用していると思う
- 755 :
- 今更MriaDBをMySQLするメリットなんて皆無なのにな
- 756 :
- 俺の業界だと普通に入札仕様の条件でDBはMySQLを使用
みたいな一文出てくるな
- 757 :
- Laravelで一番好きな機能と一番嫌いな機能は何?
- 758 :
- >>756
どうせ動くか動かないかくらいの事やってるヤツには入札とか関係ないだろ
- 759 :
- 王道のMySQL8使おうや
- 760 :
- 実際Laravelって他のフレームワークに比べるとDB接続弱いよな気がするのは確かだな
この間PostgreSQLにつながらなく原因が全くわけわからなかったんだが
Laravelのバージョンをバージョンをしたら治ったし
- 761 :
- でもSQL Serverは標準で繋がるんじゃなかったっけ?
昔SQL Server使ってた事あったけどPHPのマイナーバージョン変わる度に苦労してた気がする
- 762 :
- Laravelは他フレームワークと比べると癖が強いとは思う
ちなみに奥さんは高校時代の同級生
- 763 :
- 隙をこじ開けてくんなw
- 764 :
- ちょっと教えてください
ホストのWindows 10の1903アップグレードに合わせて
cpuをintelからamdに換装したんだけど
仮想環境内のゲストosのことを完全に失念してた
ゲストWindows8.1を起動すると不思議と立ち上がり
アプリも動画再生も問題ない
デバイスマネージャでチェックするとintel系のドライバのままだけどね
このままでもいいかと思ったけど唯一php artisan serveができなくなってる
やっぱゲストosをクリーンインストールしたほうがいい?
誰か同じような経験した方います?
- 765 :
- >>764
どんなエラーが出てるのか
ネットワークのプロパティみたらNICが消失してるとかないか?
- 766 :
- 多分ネットワーク周りの設定がおかしくなっていて
artisan serviceがbind出来なくなっていると思われます。
- 767 :
- >>765-766
ありがとうございます。
今確認してみたらなぜかゲストOSのNICが190個認識されていました。
諦めて再インストールします
- 768 :
- まずipconfigでおかしくないかみてみ?
- 769 :
- NIC190個誤認識とかやばいなw
- 770 :
- 俺は仮葬ディスクが1個のはずなのに3個になったことはあったな
ホストOSを再起動したら治ったけど
- 771 :
- すみません。質問です。
Laravelでバッチ処理を書こうと思うのですがデファクトスタンダード的な
手法ってあるのでしょうか
- 772 :
- php artisan make:command
あとはググれ
- 773 :
- 質問していいでしょうか
Vueをtypescriptで書いて、property-decoratorで@Emitデコレータを使いたいときに
外部ファイルからimportしたvueインスタンス(仮にextvm)に
イベントをemitしたいときってどうやればいいのでしょうか
this.$emit('call')
に
@Emit() call{}
は相当していますが
extvm.$emit('call')
を投げるにはどうすればいいのだろうかという疑問です
property-decoratorの公式も見てみたのですが
例は全部this.$emitの置き換えばかりで分からなかったので
詳しい方いらっしゃいましたらお教えいただければ幸いです
どうぞよろしくお願いいたします
- 774 :
- \殺伐としたスレに鳥取県が/
______________________________
-------------省略-----------
_____________________________
鳥取の見どころ6:大山
大山は標高1,729mの成層火山である。しかし、活火山では無い。神奈川県にある「大山(おおやま)」と間違える人がいるが、読み方は(だいせん)である。夏にはキャンプ&登山、冬はスキーができ、他にもアスレチックやカヌー等もある。
また、大山の名を冠した地鶏や牛乳もとても美味しい
- 775 :
- >>773
vueスレでも誰も分からんならここも無理じゃね?
違う方法考えた方がいい
- 776 :
- Laravel使った案件に入るので事前勉強してるのですが
DIのメリットがいまいちわからないです
色々読みましたが結局クラス内でnew()でも良くないか?と思ってしまう
大規模開発の際に効果を実感するらしいけど
開発の経験もないので想像力に乏しく、ピンときません
座学しか出来ない現状で理解するにはどうしたらいいでしょう…
- 777 :
- >>776
じゃ、聞いても想像できないと思うよ。
結局、デザイン系は「困った後」でないとほんとうの意味で理解できない。
- 778 :
- 疎結合って言葉だけでもググっとけ
- 779 :
- >>776
開発の都合上、呼び出すクラスがまだ作り終わっていないときでも、スタブに差し替えることでテストする事ができる。直接newだとそれができない。
あとは本番では実行するSocket通信とかの処理をテストではしたくないときに、テスト用のクラスに差し替えるとか
- 780 :
- そのうちDIがないと生きていけない体になるよ
- 781 :
- DIは死に至る病
- 782 :
- それDT
- 783 :
- でもお前らもはやDIがないとコーディングできない体になっちまっただろ?
- 784 :
- DIと俺が密結合した
- 785 :
- >>779
顔真っ赤で草
- 786 :
- みんなLaravelでアプリ作る時っフロントエンドどうしてる?
laravel-mix使ってVueで作ってる?
それともそういうのは使用せずLaravelのviewですべて作ってる?
- 787 :
- 他人に聞かないと先に進めないやつ
- 788 :
- だって長いものに巻かれたいじゃない?
- 789 :
- 今までフロントとバックエンドを分ける必要がないアプリばっかり
作成していたからlaravel-mixって使ったことないな
- 790 :
- >>786
React使ってるよ
慣れたらVueより明快でいい
- 791 :
- 静的とのハイブリット
管理者、公開ページそれぞれでjs読み込むけどそっからはvue-routerの出番
- 792 :
- Vueだね。大規模ならReact 小規模ならVueと使い分けてる。
- 793 :
- 月末出る津耶乃本の実践編でLaravelとフロントの連携方法についての章があるみたいだね
- 794 :
- もうつやのはいいよ…
- 795 :
- お前らつやのにトラウマでもあるのか?
- 796 :
- 京アニが放火されたってマジか。
- 797 :
- kwsk
- 798 :
- ニュー速板へ
京アニ作品は俺も毎回楽しみにしてるほどだが流石にスレチ
- 799 :
- >京アニ作品は俺も毎回楽しみにしてるほどだが
この情報いりますかねぇ・・・
- 800 :
- 隙を見せるのが悪い
- 801 :
- $_SERVER["REQUEST_URI"]
\Request::server('REQUEST_URI')
2つは同じものだと思ってたけど違ってこの仕様のせいで1日潰れた
勝手にケツのスラッシュ取るなよ
- 802 :
- 違った同じだったわ。テストコード中で勝手にケツスラッシュ取られてた
- 803 :
- railsとlarabel使えるけどぶっちゃけそんな変わらんよな
簡単なのはララベルかな
- 804 :
- 今のWEBフレームワークはRailsに引っ張られ過ぎなんだよ。
だからどれもこれも、規模がデカくなると破綻するんだよ。
- 805 :
- じゃあどうすりゃええの
- 806 :
- 472とかぶるけど
vue.js を使ったおすすめの管理画面テンプレート教えてくれ
- 807 :
- >>805
俺が作った最強のフレームワークあるけど?
- 808 :
- >>807
公開しろ
- 809 :
- React+Babel+Webpack 始めた。
誰一人俺のしている仕事に興味ないらしいから
金もらいながら勉強できて楽でいい。
- 810 :
- >>809
TypeScriptで書け
- 811 :
- >>809
php artisan preset react
使わずに?
- 812 :
- >>810
TypeScriptはjQueryとの共存が異常にめんどくさくなるので止めた。
>>811
自分で構築しなければ勉強にならんだろ?
- 813 :
- そもReactとjQueryは同時に使わんだろ
機能によってはDOM取得に使わなくもないが昨今は標準機能も充実だし
- 814 :
- >>813
既存システムからソフトランディングさせつつ移行して行くには併用するに決まってんだろ。
ちょっとは実務って物を考えろよ。
- 815 :
- >>812
そもそもjQueryと共存したらReactの勉強にならんからjQuery抜きでちゃんと一通り作れるようにトレーニングした方がいいよ
- 816 :
- またいつものjQuery爺か
ほっとけ
- 817 :
- >>815
ならねぇわけねぇだろ、バカか
- 818 :
- タイミング問題とか色々多発するからDOMの直接利用みたいなのは極力やめた方がいいよ
- 819 :
- >>818
そんな事するって誰が言ったんだよ、おまえらはあjQueryはDOM操作しかしらねぇのか、ボケナス
- 820 :
- >>818
それはお前が使いこなせていないだけ
- 821 :
- 1ヵ月後の自分に怒られるやつや
- 822 :
- ajax通信ならaxiosだろ
- 823 :
- 具体的にReactと共存させてjQuery何に使うの?
- 824 :
- まさかajaxにjQuery使ってんのかこいつ
だったらただのバカ
- 825 :
- >>824
バカはおめーだ
- 826 :
- >>823
extend
- 827 :
- extendって使った事なかったけどそれって
const mix = {...a, ...b, ...c}
ってやりゃいいんじゃない?
- 828 :
- JavaScriptのスプレッド構文ってヤツ
- 829 :
- extendの変わりはextendsがあるから
- 830 :
- おまえら、何トンチンカンな事いってんだ。
本当にjQueryをDOM操作でしか使ってなかったのか?
バカか!
- 831 :
- だからextendの他は何だ?
大体何を挙げられてもほぼほぼ代替策が挙げられると思うぞ?
- 832 :
- >>831
なに話すり替えようとしてんだ、腰抜け
- 833 :
- ググった限りだと
jQuery.extend() or $.extend()
くらいしか出てこないけどこれのことじゃねーの?
これスプレッド構文で展開したヤツをカンマで繋いで{}括弧で括って再結合するのと同じ事だと思うけど
- 834 :
- スプレッド構文だとprototype引き継がなくね?
- 835 :
- 継承として使うんならそれはクラスとして書いた方がいいだろ
- 836 :
- ああclone用途って事ね
extendは両方で使えたから論点理解してなかったわ
- 837 :
- おーい、おまえらー、頭大丈夫かー?
jQueryのextendって言ったら、プラグイン作ったりjQuery自体に新しい機能追加したりする機能だぞー。
そうやってつくってある旧資産を有効活用しながら、ソフトランディングさせつつ環境を切り替えていく実務の話をしているんだぞー。
おまえら、頭病気かなんかかー?
- 838 :
- jQueryなんて長らく使ってないからしらんがな(´・ω・`)
- 839 :
- >>838
はい敗北者認定!!
- 840 :
- これって僕が考えた最強のフレームワークおじさんと同じ人なの?
- 841 :
- 最強フレームワークおじさんはすでに最強だからReactなんかに頼らないのだ
- 842 :
- 自分のフレームワークの長所も説明できないアホかwそんなやついたなぁwww
どうせ今回も何に使ってるか説明できないんだから放置しとけばいいんじゃね?
そもそも根本で頭悪いことやってんだから興味持っても意味ないし。フレームワークのときと同じじゃん。
- 843 :
- >>842
妄想で草を育てる農夫
- 844 :
- うわ。まじでフレームワークおじさんかよ。。。
放置決定だな。
- 845 :
- 農夫捨て台詞を吐いて畑仕事に戻る、
- 846 :
- ファットコントローラーにならんためにjQuery拡張ねぇ
- 847 :
- >>846
ちげーよ、バカ
- 848 :
- ファットコントローラにしないためにjQueryとかww
- 849 :
- >>848
ちげーっつってんだろ、脳みそウニかおまえ
- 850 :
- jQuery拡張すれば確かにコントローラー負担を軽減できるか…
- 851 :
- 管理画面がSPAで作られてるのって保守大変だわ
画面遷移が必要なところは画面遷移入れろよな
- 852 :
- ルーターモジュール入れずにSPA作るのは流石に悪手だな
- 853 :
- SPAの方が楽じゃね?
入力値一つとってもバインドさせるだけで済むものがサーバーでバリデーション反映したページで入力値保存の為にセッション使ったりと静的ページの方がめんどい
- 854 :
- ファットコントローラおじさんまだいたのか
しかもjQueryでがんばって解決しようとしてるとかwwwwww
- 855 :
- 爺Query
- 856 :
- https://i.imgur.com/QSgTWWQ.jpg
- 857 :
- お前らどうせアニメ好きなんだろ?って思ってそういう画像貼ってるのかも知れんが
正直キャラクターの政治利用は完全に逆効果
- 858 :
- >>856
関係ないからこっち来んな
- 859 :
- >>857
おっ?長文きちゃった
悔しかったねぇw
- 860 :
- 政治利用と言えばこれ
https://pbs.twimg.com/media/D_jH6OEX4AMdr4h.jpg
- 861 :
- お前らたまにはLaravelについて話そうぜ
ここはぁんLaravelのスレッドなんだからさ
- 862 :
- >>861
あえぎながら言われましても…。
- 863 :
- laravel6くるらしいね
- 864 :
- vue使おうと思ったけど、シングルページアプリケーション作らないから要らなかった
- 865 :
- シングルページアプリケーションって何ですか?
- 866 :
- 調べろ
- 867 :
- spaじゃなくてもvue使っていいでしょ
- 868 :
- 実際バインドさせるだけでデータがViewと同期してくれるのはガジェット作りにも便利だよな
- 869 :
- ということはガジェット作りに便利ということか?
- 870 :
- ReactはほぼWebpackとセットなのが前提だけど、VueはVue.js単体を読み込んで使う方法もある
一部DOM部分だけをVueに置き換えることも手軽に出来る
- 871 :
- 改修ならそうだけど新規ならSPAのビルドでやらない理由もない
- 872 :
- >>867
それ意味あんの?
- 873 :
- >>872
htmlをjsで操作するなら選択肢に入る
- 874 :
- laraverでREST作ってデータ取得からフロントまでWordpressで管理なんていうこと考えたけどどうだろう
逆に面倒か
- 875 :
- >>874
どゆこと?
ララヴァーはともかくとして
- 876 :
- WordPressにaxiosとVueなりを追加して既存テンプレートの恩恵を得ようって事だと思う
PHPがサーバーサイド、フロントエンドサイドに分かれてDBも分かれるので設計が大事になるかと
WordPress側のDBを使わないならいいけどデータを両者に持たせるとカオスな事に
- 877 :
- どゆこと?
- 878 :
- http://e-village.main.jp/gazou/image_gazou/gazou_0129.jpg
- 879 :
- LaravelがSpringBootと合体するらしいな
- 880 :
- >>812
でもやっぱり島耕作がSランクだと思う。
初芝時代の田島部長だとよくてEランクじゃないかな。
中沢さんは今より上のランクに上げてもいいと思う
- 881 :
- すみません。島耕作最強議論スレと間違えて誤爆してしまいました。
- 882 :
- >>879
マジ? どこ情報?
- 883 :
- 島耕作最強議論スレとかいうパワーワード
- 884 :
- SpringBootをまねしたLaravelBootが出るってだけじゃないの?
- 885 :
- 今ふと「フルスタックフレームワークでググったらLaravelは何位くらいかな」とスマホで調べたら電車の中で吹いた
ジロジロ見られて超恥ずかしかったわ
- 886 :
- ジロジロみられるって音声認識で検索してんの?
- 887 :
- どんな感じで吹いたのか詳しく
- 888 :
- 釣れたな
- 889 :
- >>886
普通にググったら想定外の画像が出たもんでつい
>>887
「ふんぐっ」て感じ
目の前の人達と目が合って超恥ずかしい
明日同じ時間に乗り合わせないことを願う
>>888
見事に釣られたよ…
- 890 :
- 確かに笑うわこんなん
- 891 :
- 大物だな・・・
- 892 :
- ああああああああああああああああああああああ
>>889のせいで俺も電車で吹いちまった
検索するんじゃなかった・・
- 893 :
- 俺も電車でやっちまった
- 894 :
- 別に吹く程の画像じゃないだろ
りゅうちぇるの方がよっぽどヤバい
- 895 :
- 言うほど面白いか?
- 896 :
- 分かってて見たらそうでもないが
「Laravelが何位か」の脳で飛び込んできた画像なら面白いだろうな
- 897 :
- 文字通りアングラーだな
- 898 :
- おれも検索したw この人に会ったことあるからなおさら面白かったわ。
- 899 :
- 大昔はLaravelで検索するとインターネットフリー素材でおなじみ
ぼっさんの画像が出てきたんだけどな
- 900 :
- LTSがVer 6.0になったか
- 901 :
- >>900
また結構変わってるみたいね。
- 902 :
- >>901
説明よろ
- 903 :
- >>901
kwsk
- 904 :
- https://laravel.com/docs/6.0/upgrade
- 905 :
- requires PHP 7.2 は結構しんどいとこもありそうね。
- 906 :
- うち7.1だわ
- 907 :
- Laravel 6.0 LTS
何がどう変わったのか1ミリも知らないけど
とりあえずおめ
- 908 :
- Laravel6.0使ってみたけど凄いな
アプリケーションの速度が今までと比べて10バイブになtった
- 909 :
- ちょっとよく分からないからガンダムで例えて
- 910 :
- 5.8からそのままでは動かんのだろうなぁ
- 911 :
- ということは5.8で動かない可能性があるということか?
- 912 :
- https://laravel-news.com/running-make-auth-in-laravel-6
やばいな。全然変わってそうw
早めに試してみたほうがいいな。
- 913 :
- エラー感のあまりない新エラー画面
- 914 :
- とりあえず知見貯まるまで放置で
- 915 :
- 正直、FWのメジャーアップグレードで大幅な変更が必要になったら、
他の言語への移行とか考えちゃったりしない?
- 916 :
- いやーlaravelは工数大幅に減らせるかlaravel使っちゃうね
- 917 :
- 速度面どうなったのかな
- 918 :
- >>4
えじゃあオススメのフレームワークあるの?
あなたの書いてることってフレームワーク全否定以外の何物でもなくね?
私はCakeかRoRが現状では一番だと思うけど
DjangoとGoは触ったことないす
- 919 :
- GoはGinかEchoが主流だけど小規模でもSwaggerは使った方が良い気がする
素でRoute書いてるところ少ないし
フロントエンドはSPAで書く方がむしろ楽になる
上の2つはRESTフレームワークだし、templateエンジンってあんま発展してないし
後はまあコンパイラ言語なんでコンパイラの恩恵が便利
- 920 :
- >>918
複雑にならないように、分離できない人なんじゃない?
PHPに分離できるFraneworkまたはその方法があるか
知らんけど。
- 921 :
- 型ある方がいいよ絶対
- 922 :
- Railsなんかでたまに大規模プロジェクトのリファクタリングで
未使用メソッドの削除にログ仕込んで何か月もかけて取り組み数千・数万行を削除
なんて企業ブログあるけどあんなのもコンパイラ言語ならコンパイル走らせるだけで済むのに
- 923 :
- 6.0の仕様なのかbootstrapが読み込まれてないみたい…改善策教えてけろ
- 924 :
- >>923
参考程度に
https://qiita.com/ucan-lab/items/bd0d6f6449602072cb87
- 925 :
- >>924
サンクス!でもそのサイトのやったけど読み込まれないんよ
つーかbootstrapもバージョン変わって使えなくなったやつ増えてんのな…
- 926 :
- nodejs、npmパッケージがインストール済みか否か
resources/js/bootstrap.js内でrequire('bootstrap');の記述があるか
以下のコマンドがそれぞれエラーなく完了するか否か
$ npm install bootstrap
$ npm install
$ npm run dev
この辺全部上手く行ってるなら使えるはず
- 927 :
- >>926
トンクス!Macは簡単にインストール出来てええなぁ
ワイはWindowsやからインストール面倒いねんなぁ
- 928 :
- >>927
いやnpmのコマンドはwindowsもmacも関係ないだろ
- 929 :
- ワッツ!?
- 930 :
- いやコマンド打っても怒られるんやが…
- 931 :
- Windowsか
じゃあNodeも碌に入れてないんだろうな
https://nodejs.org/ja/
こっから最新取ってきてまずインストールしとけ
- 932 :
- 大体普通は公開サイトを置く場合レンタルでVPSとかを借りてそこにLinux、Webサーバー環境を構築してから
そこにLaravelプロジェクトを置いて公開するから
標準環境の基準はMacじゃなくてLinuxな
その辺の認識は改めておいてくれ
だからと言ってWindowsではできないってわけでは全然ない
- 933 :
- >>931
ヘイ!アニキインストールしてきやした!
でもcmdでコマンドバッチが認識されてないってでやす!!
PowerShellならバージョンでやすけどLaravelでまだ使えてないっすやす!
- 934 :
- >>932
ヘイ!
- 935 :
- コマンドラインでnpmだけで打ってもダメ?
- 936 :
- それで反応するのはPowerShellだけでやす!
なんでこんな仕様にしたんでやすかねLaravelは!!
- 937 :
- >>936
Laravel関係なしにNode.jsの仕様
Windows再起動とかやっても認識されない?
- 938 :
- MySQLにも接続できなくなりました
- 939 :
- >>937
コマンドプロンプト消してコマンド打ったら出来やした!
色々教えてくれたニキ達ありやす!!
- 940 :
- 6でもlaravel ide helperちゃんと機能してる?
- 941 :
- してないです・・・・
- 942 :
- 正直php使ってる奴は見下してる
- 943 :
- なに使えば良い?
- 944 :
- COBOL
- 945 :
- laravelが便利すぎるから他に使う必要がない
- 946 :
- ZendFramework・・・・・・・・・
- 947 :
- ZendServiceManager単体しか使ってないですサーセンw
- 948 :
- やっとfuelから卒業しました
よろしくLaravel♪
- 949 :
- >>949
kwsk
- 950 :
- リポジトリパターンでリポジトリに複数のモデルを使用するのはあり?
それともサービス用意してそっちでまとめて処理すべき?
- 951 :
- そのモデルはEloquentのことなのかドメインモデルのことなのか
- 952 :
- >>951
Eloquentです
- 953 :
- ありありのあり
- 954 :
- アリーヴェデルチ(さよならだ)
- 955 :
- 複数のEloquent Modelが親子の関係にあったりリレーションシップで辿れるような場合、要は
Repository::find()が一つのEloquent Modelを返すだけで済む場合はアリかな
そうでないなら複数のEloquent Modelを組み合わせたモノが何らかの意味を持つはず。その場合はその概念に名前をつけてやって複数のEloquent Modelを中に持つクラスを作ったほうが良いと思う
- 956 :
- 全てのEloquentModelを内包するGodクラス作りました…
これでかつる…
- 957 :
- おれはDevilクラス作ったぞ
- 958 :
- お前らのModelクラス使用するとN+1問題引き起こしそうで怖い
ちゃんとN+1が発生しないことを確認してますカクレンジャーレッド
- 959 :
- 【速報】Laravel6リリース
- 960 :
- 遅報すぎやろ
- 961 :
- 結局PHP最強のフレームワークはLaravelでOK?
- 962 :
- Phalcon
- 963 :
- Phalcon爆速らしいな
普通のフレームワークでワザと処理が1分ぐらいかかるような
糞思い処理を書いて
それと同じアルゴリズムをPhalconでやると0.1秒で終わるらしい
- 964 :
- LaravelでPhalcon使う方法教えてください
- 965 :
- Symfony4がさいつよでしょ
- 966 :
- Phalconは3年ぐらい前に使ったんだけど、挙動確認するために毎回Cのコードを読まないといけないのが辛くてやめた。
- 967 :
- なるほど
- 968 :
- まだフレームワークに左右される設計してるの?
- 969 :
- 俺の神フレームワークなら現在存在しているすべてのPHPフレームワークよりも
上だよ
- 970 :
- よかったでちゅね〜
- 971 :
- >>970
顔真っ赤で震えているのは何で?
- 972 :
- 実際PHP最強のフレームワークって何になるの?
Symfony?Laravel?
- 973 :
- 気が付いたら6.2になってた
- 974 :
- バージョンアップの内容は?
- 975 :
- 強くなった
- 976 :
- 従来のLaravelよりも高速で動くようになった
- 977 :
- 6.2凄いな
お前らも早くバージョンアップするんだ
- 978 :
- Laravelもすごいけどsymfony/skeletonもすごい気がする
- 979 :
- rails使いだが正直phpは見下してる
- 980 :
- そろそろ新スレ?
- 981 :
- intellij ideaってインテリジェーアイデアであってますか?
- 982 :
- インテリジェイデアってよんでた
- 983 :
- でもそれだと難しいよね
- 984 :
- なんの疑いもなく「インテリジェイ アイデア」だと思ってたけど、皆それぞれ違うもんなんだな
そういやASUSも俺ずっとエーサスだと思ってけど後でアスース(更にその後でエイスース)が正式な読み方だったのはショックだったわ
Laravel、日本語圏ならララベル一択で良いよね…?
- 985 :
- >>984
ララーベル?
- 986 :
- ラルベル
- 987 :
- ぁらう゛ぇる
- 988 :
- ラ↑ラベル
- 989 :
- ぅルるぁヴェぅル
- 990 :
- ベララルラー
- 991 :
- ラファエルもw
- 992 :
- 開発のしやすさはやっぱりこいつが一番やね
- 993 :
- 6.2インストールしてみたけど、どう動かせばいいかわからん
- 994 :
- この前6.0になったのにもう6.2かって思ったけどこれからはマイナーアップデートは頻繁に来るのか
- 995 :
- もう6.5じゃねぇかw
- 996 :
- 早すぎてドキュメントが追いつかんな
- 997 :
- APIのインターフェースは変わらんって話だし内部実装まで追いかける人じゃなければ気にしなくていいはず
- 998 :
- ドキュメントは今後は6.xで一括りでしょ
- 999 :
- バージョニングのルールがsemantec versioningに従うように変わっただけ。
以前なら6.0.5だったのが6.5としてリリースされてる
- 1000 :
- 質問良いですか?
- 1001 :
- 2ch.scからのレス数が1000に到達しました。
- 1002 :
- 2ch.scからのレス数が1000に到達しました。
Webプログラマーになるためには
PHP を流行らせるには
【質問】ASP.NETスレ Part7【雑談】
一番汚いコードでHello Worldを書いたやつが勝ち
DBの絡んだWEB制作の相場
クロスサイトスクリプティング対策
Apache2.x 【新鯖入荷しました】
ウェブプログラミングで使えるデザインパターン
PCに関連するものすべてにおいて中級になりたい
【Python】Webフレームワーク Djangoスレ Part2
--------------------
【サイコパスの】今江パク隆54【真夏のホモ祭り!】
MMT MMTer Twitter
【Poser】RWBY 8【Rooster Teeth】
【とある魔術の禁書目録】インデックスちゃん59.5冊目
やってるな?
DC UNIVERSE ONLINE
【悪質タックル】アメフト反則行為 関西学院大学の負傷選手 警察に被害届★2
パートについて◇IDなし◇パート131
●虫●SO3のバグを攻略するスレ その2●凍●
【眉毛貴公子】高瀬耕造 Part5【おはよう日本】
なぜ広島は優秀な人材の宝庫なのか10
毒親育ちが語り合うスレ in生活サロン
将来出るドラクエの副題を勝手に付ける
人口二十万人以下の田舎市町村出身者
†† 小公女セーラ 149話 ††
関東鉄道バススレッド34
【MHW】ベヒがエリチェンしたときに先陣切って行くのを嫌うやつwwwwwwwww
高速コンテナ貨車コキ10000系
【FIGHTERS】札幌ドームを語るスレ2【コンサ】
フラッシュライト 免許と仲良く! 417ルーメン
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼