追記

下記の方が、便利なライブラリを作成してくれています。
古のphpバージョンだと対応していない(未確認)ので、以降の記事は備忘録的な意味で残します。
https://qiita.com/mpyw/items/0761a5e44836c9bebcd5

難しいクエリを作りたくない

whereHasは遅い。激遅い。
left joinや、whereInすれば良いらしいと推測。
でもleft joinはコーディングがしんどいのよな……。

結論：whereInで頑張れば簡単だし改善はできるよ

modelの関係性

usersはcommentsと「1対多」の関係。

whereHasを用いた場合

前提

• リレーション先のカラムでwhereしたい。
• 姓と名が別々のカラムになっており、concatでlikeしないとならない。（この条件は今回関係ない）

UsersController.php

Comments::whereHas('Users', function($query) use ($user_name){
$query = $query->where(DB::raw('CONCAT(mei, sei)'), 'like', "%$user_name%");
});

whereInに置き換え

UsersController.php

// users単体で、クエリをたたく
$users = User::where(DB::raw('CONCAT(mei, sei)'), 'like', "%$user_name%")
            ->select('id')
            ->pluck('id')
            ->toArray();
// その結果を、当モデルに組み込む。
Comments::whereIn('user_id',$users);

計測はしていないけど、体感で明らかに早くなったのでよしとする。
生クエリや、left joinする方とどちらのコーディングが美しいかは言うな。
僕みたいなよわよわ頭脳の場合は上記の方が早く書けるし、見やすい！

以上。

はじめに

Laravelを勉強中です。備忘録として残しておきます。

手順

サービスプロバイダーの作成

app/Provider/ComposerServiceProvider.php

<?php
namespace App\Providers;

use Illuminate\Support\Facades\View;
use Illuminate\Support\ServiceProvider;
use Illuminate\Support\Facades\Auth;

class ComposerServiceProvider extends ServiceProvider
{
    public function boot()
    {
        View::composer('*', function($view) {
            $view->with('user'(使いたい変数名), Auth::user()(使いたいデータ));
        });
    }
}

View::composerの第一引数「*」はすべてのviewという意味。

作成したComposerServiceProviderの登録

config/app.php

    'providers' => [
        .
        .
        .
     App\Providers\ComposerServiceProvider::class,
    ],

これですべてのviewで使用できるようになります。

参考にさせて頂いたサイト

https://www.webopixel.net/php/1287.html

Laravelで開発をしていて、composerでライブラリを導入したいときにメモリが足りなくて怒られたので備忘録として残します。

発生事象

Allowed memory size of 1610612736 bytes exhausted...として怒られます。
意味としては、割り当ててあるメモリを使い果たしたよってことです。

$ composer require laravel/socialite

Using version ^5.1 for laravel/socialite
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)

Fatal error: Allowed memory size of 1610612736 bytes exhausted (tried to allocate 4096 bytes) in phar:///usr/local/bin/composer/src/Composer/DependencyResolver/Solver.php on line 223

Check https://getcomposer.org/doc/articles/troubleshooting.md#memory-limit-errors for more info on how to handle out of memory errors.

対策

以下のコマンドを実行することで、解消できました。

COMPOSER_MEMORY_LIMIT=-1で、一時的にメモリの制限を解除しています。
which composerで、composerのパスを持ってきて渡しています。

$ COMPOSER_MEMORY_LIMIT=-1 $(which composer) require laravel/socialite

Using version ^5.1 for laravel/socialite
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Nothing to install or update
Generating optimized autoload files
> Illuminate\Foundation\ComposerScripts::postAutoloadDump
> @php artisan package:discover --ansi
Discovered Package: facade/ignition
Discovered Package: fideloper/proxy
Discovered Package: fruitcake/laravel-cors
Discovered Package: laravel/sail
Discovered Package: laravel/socialite
Discovered Package: laravel/tinker
Discovered Package: laravel/ui
Discovered Package: nesbot/carbon
Discovered Package: nunomaduro/collision
Package manifest generated successfully.
73 packages you are using are looking for funding.
Use the `composer fund` command to find out more!

参考

composer update でメモリオーバーする場合の対策
https://qiita.com/ucan-lab/items/af39b71c6eb304ddf696

こんにちは。web系を中心としたプラグラマをしております。
小さなミスからそこそこ大きめのミスまで、今年1年でたくさんのミスをしてきました。
まだ新人で大きな権限を頂いていないこともあり、本番環境でやらかしてしまった皆様ほどのインパクトあるやらかしはないのですが、コーディングや開発環境構築などであれこれ反省点があるのでまとめていきたいと思います。
アンチパターンやあるあるとしてお楽しみ下さい。

・コーディング系
・環境系
・人として

コーディング系

誤字

とにかく多かったです。
クラス名や関数名ならすぐエラーが発生して見つけやすいのですが、phpで変数名のスペルミスをしたりすると、そのままnullが代入されたりして見つけづらく、時間の無駄になりがちでした。

$address = 'hogehoge';
print $adress; // 返却値なし

くだらない誤字ですが、この手のエラーが出ない誤字で無駄にした時間も、年間を通せばかなり膨大になって来ます。
解決策としては、コードを細かく切り分けてこまめにテストを実行しました。これによって誤字箇所を発見するのが早くなった実感があります。
また、エディタはVSCodeを使用しており補完機能は元々使っていたのですが、コード量が多いとなかなか読み込まず使用を諦めて手入力することもあったので、今後補完機能をうまく活用できるように工夫していきたいです。
......そんなことより静的言語を使った方がいいのかもしれません。

エスケープ

先日LaravelのselectRawメソッドを用いて生に近いSQLを書く機会がありました。WHERE句の対象となるカラムにバックスラッシュを用いたパスが入っていて、この部分をエスケープ出来ておらず検索結果が0となる失敗を犯しました。この質問と大体同じ内容です。

// 失敗例
DB::table('hoge')
    ->selectRaw('* WHERE `path`="PATH\\TO\\SOME\\MODEL"')
    ->get();

一見エスケープ出来ていそうですが、phpではダブルクォート内ではバックスラッシュが // → /となり、かつ、Laravelのraw関係のメソッドではエスケープされない(というかrawって書いてあるのでそりゃそうですね)ので、MySQLに送られるクエリは以下のようになります。

SELECT * FROM hoge WHERE `path`='PATH\TO\SOME\MODEL' 

結果、MySQLでもエスケープされて無事死亡しました。
できるだけこのような生っぽいSQLは書かないのが一番ですが、この時は諸事情で仕方なかったので、以下のようにして解決しました。

// 成功例
DB::table('hoge')
    ->selectRaw('* WHERE `path`="PATH\\\\TO\\\\SOME\\\\MODEL"')
    ->get();

SELECT * FROM hoge WHERE `path`='PATH\\TO\\SOME\\MODEL' 

ともかく、何かとバックスラッシュは問題のタネになりやすいので警戒していきたいと思います。

環境系

Dockerコンテナの内か外か

Dockerを立ち上げてシェル作業する時、必要なコマンドをコンテナの内側で行うのか外側で行うのかを間違えて command not found になったり、最悪の場合想定外の処理が始まったりします(しました)。
基本的にどのコマンドをどこで実行するのかはプロジェクトによるので、実行前に確認するようになりました。特にcomposerの実行場所で事故ったので気をつけていきたいと思います。

バージョン違い

composerで依存パッケージをインストールすることが多いのですが、マイナーバージョンは指定しておらず不具合が発生する場合があります。
また、私が今年特に詰まったのはcomposer自体のバージョン違いです。
2020年10月頃にcomposerのバージョン2.0がリリースされました。これに気づかずdocker-composeコマンドを実行してしまった結果、DockerFile内にcomposer関係の諸々のコマンドが実行されてしまい、大量のエラーが発生しました。
この件の解決策は、こちらの方と同じ方法を使いました。
コマンドは以下のものです。

curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --1 --filename=composer

バージョンアップの詳細はこちらです。
　　　　　　　　

人として

連絡が遅い

思い出すと胃が痛くなります.......
進捗が悪いのに、頑張って挽回しようと試行錯誤していて締め切りギリギリまで上司への進捗が遅れている旨の連絡をしませんでした。上司からは特に怒られず、淡々と「了解です。次は早めに連絡・相談して下さい」という内容のメッセージが返ってきて逆に怖かったです。
とにかく、早めの報告・連絡・相談は本当に大切です。技術的なミスより何より連絡不足が一番信用を失うと思いました。

仕様通りでない

仕様変更が頻繁でも、仕様書が読みづらくても、決定した仕様が一意である以上、仕様通りでないのは絶対にダメですよね。
コミット前にもう一度、成果物のチェックを怠らない。大事だと思います。
あと、最初に仕様書を通しで読んだ時に矛盾点を見つけられるようになりたいです。実装を始めてから気づくことが多いので.......

まとめ

結局、ほとんどのミスが確認不足に起因していました。
コミット前、コマンド入力前、上司への報告前......この記事を振り返ってミスを減らしていきたいと思います。
というわけで、皆様1年間お疲れ様でした。2021年も頑張っていきましょう！！