LaravelでAuth系のコントローラが最初から存在するのはなぜか

Laravel

ご存知の通りLaravelではartisan make:authすることでいくつかのファイルが生成・変更され、デフォルトの認証関係の機能を有効にできる。

だが、じつはこれを実行しなくとも、最初からApp\Http\Controllers\Auth\LoginControllerをはじめとする各種コントローラが存在している。

GitHubで履歴を辿って調べてみた。確証はないがおそらく、単純な歴史的経緯が理由のようだ。

認証用のコントローラが laravel/laravel (Laravelのフレームワークのコア部分を除いたリポジトリ。いくつかのサンプル的なコードが含まれる)上で実装されたのは5.0のころ1のようだ。

この時点ではmake:authはなかった。こちらは5.2のころ2に実装されている。

もう一つ興味深いのが、このとき実装されたmake:authが一度削除されている3ということだ。各種ファイルがlaravel/laravelにすでに含まれているから不要という理由で削除されている。このときは5.8現在とは違い、make:authが認証用のコントローラも生成していたようで、そのせいで重複と考えられたのだろう。

その後5.2のうち4に再度実装され、今度はlaravel/laravel側で存在するコントローラは生成されない形で実装された。

ということで歴史だけ見ると、先にlaravel/laravel内のファイルとして実装してしまったので、というだけでほかの理由などはなさそうだ。

現状はいまいちなので、laravel/laravelから認証用コントローラを削除し、make:authで生成できるようになって欲しいが、リポジトリが違うことからいろいろ面倒そうではある。

余談なのだが、make:authの実体となるファイルは一度削除される前と後で名前が変わり、さらにその後再度名前が戻される形で変更されており、そのせいで履歴を辿るのがちょっとややこしい。5

  1. https://github.com/laravel/laravel/commit/f2279c02107f28b8c3cb1b8627c22a6fb2e7fc74↩

  2. https://github.com/laravel/framework/commit/29c9ba0197179c018a20df30f3330b90de0923a9↩

  3. https://github.com/laravel/framework/commit/f7070f3092aa350f991125a294bbec0475cf6aa0↩

  4. https://github.com/laravel/framework/commit/6f07584f9b80d51c80fab0fd35285401dc7e9967↩

  5. AuthMakeCommand, MakeAuthCommand↩

ChocolateyでStrawberry Perlが更新できない

Perl Windows

chocolatey upgrade strawberryperlすると、

WARNING: Generic MSI Error. This is a local environment error, not an issue with a package or the MSI itself - it could mean a pending reboot is necessary prior to install or something else (like the same version is already installed). Please see MSI log if available. If not, try again adding '--install-arguments="'/l*v c:\StrawberryPerl_msi_install.log'"'. Then search the MSI Log for "Return Value 3" and look above that for the error.
ERROR: Running ["C:\Windows\System32\msiexec.exe" /i "C:\Users\********\AppData\Local\Temp\chocolatey\StrawberryPerl\5.30.0.1\strawberry-perl-5.30.0.1-64bit.msi" /qn /norestart /l*v c:\StrawberryPerl_msi_install.log] was not successful. Exit code was '1603'. Exit code indicates the following: Generic MSI Error. This is a local environment error, not an issue with a package or the MSI itself - it could mean a pending reboot is necessary prior to install or something else (like the same version is already installed). Please see MSI log if available. If not, try again adding '--install-arguments="'/l*v c:\StrawberryPerl_msi_install.log'"'. Then search the MSI Log for "Return Value 3" and look above that for the error..
The upgrade of strawberryperl was NOT successful.
Error while running 'C:\ProgramData\chocolatey\lib\StrawberryPerl\tools\chocolateyInstall.ps1'.
 See log for details.
 Unsuccessful operation for strawberryperl.

とか出る。

書いてある通り、

--install-arguments="'/l*v c:\StrawberryPerl_msi_install.log'"

を追加して再実行してみる。出力されたログにこんなことが書いてあった。

MSI (s) (E8:F8) [09:12:05:418]: Doing action: CA_UninstallOldVersion
Action ended 9:12:05: FindRelatedProducts. Return value 1.
Action start 9:12:05: CA_UninstallOldVersion.
MSI (s) (E8:F8) [09:12:05:418]: Product: Strawberry Perl (64-bit) -- Already installed version of Strawberry Perl (64-bit) cannot be upgraded; it has to be uninstalled first.

Already installed version of Strawberry Perl (64-bit) cannot be upgraded; it has to be uninstalled first.
Action ended 9:12:05: CA_UninstallOldVersion. Return value 3.
Action ended 9:12:05: INSTALL. Return value 3.

先にアンインストールしろってことかな？

C:\Users\********\AppData\Local\Temp\chocolatey\StrawberryPerl\5.30.0.1\strawberry-perl-5.30.0.1-64bit.msi

にあるのを直接叩いてみると、GUIで同じことを言われた。

つまりChocolateyのStrawberry Perlのパッケージでは、前のバージョンがうまくアンインストールできない(ことがある？)らしい。

もうちょっと調べたい気もしたが、今回はここまで。とりあえず手動でアンインストール後、再度、

choco upgrade strawberryperl

した。

Tridactylでデフォルトのsearchurlsのキーワードを無効にする

Tridactyl Firefox

Tridactylではデフォルトで各種キーワードでの検索が設定されている。が、キーワードが名前そのままなので、キーワードと同じ単語を検索したい場合につらい。ので無効にしたいのだが、しばらくやり方がわからず、試行錯誤の末最近ようやくわかったので共有する。

以下はデフォルトでは、Googleで、mapsが検索される。

:open google maps

これを、google mapsというキーワードでデフォルトの検索エンジンでの検索にしたい。

結論から言うと、以下のようにsearchurlsのJSONを直接設定し、キーワードの値を空文字列にする。

:set searchurls {"google": "", ...}

引っかかる点としては、設定をクリアしようとするとデフォルト値が使われてしまうこと、またsearchurls.<KEYWORD>の形のショートカット経由で設定を空文字列にすることはできないということ。

:unset searchurls.google

設定がデフォルトに戻る。

:set searchurls.google

後ろに空白。後ろに空白がない場合と同じように、現在の設定を表示するだけ。

:set searchurls.google ''
:set searchurls.google ""

それぞれ'', ""自体が設定されて、検索はされずエラーになる。

Google Chartsで列に有効なデータがある場合は問題ないのにない場合にエラーになる件

JavaScript 
var data = google.visualization.arrayToDataTable([
    ['date',       'number'],
    ['2019-05-13', 1],
    ['2019-05-14', 2],
    ['2019-05-15', null]
]);

では問題ないのに、

var data = google.visualization.arrayToDataTable([
    ['date',       'number'],
    ['2019-05-13', null],
    ['2019-05-14', null],
    ['2019-05-15', null]
]);

の場合にチャートを描画すると、

Data column(s) for axis #0 cannot be of type string

というエラーが出る。

どうも列にデータがないと型を推測できないからエラーになっている感じっぽくて、型を指定したら問題なくなった。

var data = google.visualization.arrayToDataTable([
    [
        'date',
        { label: 'number', type: 'number' }
    ],
    ['2019-05-13', null],
    ['2019-05-14', null],
    ['2019-05-15', null]
]);

Eloquentのwhen()で、偽になる可能性のある値の存在を条件に検索する

Laravel

Eloquentというかクエリビルダ側の機能だけどまあ。

when()はこのように使うことができ、条件分岐を何度も何度も書かなくて済む。

<?php

use Illuminate\Database\Eloquent\Model;

class Searchable extends Model

# ...

public function search($condition)
{
    $this->when($condition['cond_1'] ?? false, function ($query, $cond_1) {
        $query->where('cond_1', $cond_1);
    });
}

# ...

ただし、フラグや数量で検索したい場合、when()の第1引数にそのまま渡してしまうとfalseや0の場合に検索自体が行われない。まあ当然なんだけど。

<?php

# ...

public function search($condition)
{
    # $condition['boolean']が偽の場合、コールバック関数は実行されない
    $this->when($condition['boolean'] ?? false, function ($query, $boolean) {
        $query->where('boolean', $boolean);
    });
}

# ...

どうするか。いろいろ考えたのだが、useでコールバック関数に直接変数を渡してしまうのがよさそうだ。

<?php

# ...

public function search($condition)
{
    # $condition['boolean']が設定されていてnullでなければ検索される
    $this->when(isset($condition['boolean']), function ($query, $boolean) use ($condition) {
        $query->where('boolean', $condition['boolean']);
    });
}

# ...

ASUSのノートPCを修理に出したメモ

日記

購入から一年後くらいからSSDの認識が怪しくなってきて、一度治ったかのように見えたものの数ヶ月後完全に駄目になったので修理に出した。ASUSのサポートセンターに直接。

こういうのって具体的にどういうフローになるのか、どれくらいかかるかなどわかりにくいため、いつか誰かの役に立つかもしれないし経緯をメモっておく。状況次第の部分も多いだろうし参考程度に。

修理に出すまで

  • +0日 直接修理に送るみたいなことはできないようなので、メールフォームから連絡。
  • +1日 メールに返信が来る。シリアル番号が必要とのことなので添付して返信。
  • +3日 メールに返信が来る。概算の見積りと、修理依頼手順が記載。

修理に出してから

  • +0日 ヤマトのパソコン宅急便で送る。BOX Aで、13インチのノートPC本体に念の為の電源アダプタも入った。
  • +1日 ASUSサポートセンターに荷物が届いた。これはヤマトからのメールで確認。
  • +2日 ASUSの修理・お預かり品の状況確認からシリアル番号で状況確認できるように。
  • +6日 サポートセンターから電話確認。修理代が一定以上になったら確認してと連絡していたため。
  • +6日 クレジットカードで支払うことにしていたため、決済のメールがペイジェントから。メール暗号化されてないし、ASUSからであることの確認はさらに難しいし、こういうフィッシングできそう。
  • +7日? 日時が残っていないのだが、この辺から状況確認がシリアル番号ではできなくなっていた。後で修理番号で確認できることを確認。なお修理番号、修理品の返却まではペイジェントの「ご注文番号」でしか確認できない。またこの番号が修理番号だという説明はない。
  • +9日 連絡なしにノートPCが帰って来た。

メールの返信や電話などの感触はよかったが、全体的なフローはちょっと不親切な感じが。こんなものなのかな。

ngrokでWordPress製のサイトを公開する

WordPress

ご存知の通りWordPressはドメイン名をデータベースに入れたりデータベースに入れたりしてるので、ngrokで動かせるようにするのはちょっとやっかい。

なのでどうするか。まあ公式ドキュメントに書いてある。

ngrok – documentation

なお既存の記事などのデータがなければ、2のWP_SITEURL, WP_HOMEをアレするだけでもとりあえずなんとかなる。

また、HTTPSでやる場合はこちらも。

<?php
# wp-config.php

# ...

$_SERVER['HTTPS'] = 'on';

# ...

HTTPとHTTPS両方やる場合どうするかについては調べてない。まあリバースプロキシの後ろでやるときみたいになんらかの環境変数見ればいいのでは？