2018年前半に読んだ本

去年は割とノンフィクションの本を読めた。60冊弱くらい。その9割くらい、Twitterで雑な感想書いてあったのでまとめる。

前半は割と軽いものを読んでいた。コーヒーにはまったのでそれ関係が多かった。

この中で一冊挙げるなら、「マネージャーの最も大切な仕事」かな。最高なのでマネージャーじゃなくても読むべき。「シリコンバレー式 よい休息」も今でも読み返すいい本。

Laravel Mixというかwebpackでconsole.log()が消えないようにする

追記

Laravel Mixとwebpackのどっちが犯人なのか探ってたら、Laravel Mixが犯人であること、さらにじつはもうdrop_consoleがデフォルトで無効になっていることに気付いた。

Remove drop_console option · JeffreyWay/laravel-mix@a9d2646 · GitHub

ということでこの記事にはもうなんの意味もない……。

追記終わり。


Laravel Mixが使っているwebpackが使っているUglifyJSにはdrop_consoleというオプションがあり、これが有効だとconsole.log()が消される。

アホなオプションなのでUglifyJSではデフォルトは無効のようだが、Laravel Mixかwebpackか知らんがどちらかでデフォルトで有効になっている。

こんなものはバグの温床でしかないので無効化したい。

以前までは、

mix.options({
    uglify: {
        compress: {
            drop_console: false
        }
    }
});

で行けたけど、(多分)uglifyjs-webpack-pluginが1.0になるあたりの変更で仕様が変わって、

mix.options({
    uglifyOptions: {
        compress: {
            drop_console: false
        }
    }
});

にしないとエラーになるようになった。

なお以下のようなエラーが出てた。

ValidationError: UglifyJs Plugin Invalid Options

options['compress'] is an invalid additional property

Laravel 5.6.27以降でログアウト後のリダイレクト先を変更したいなら、logout()ではなくloggedOut()をオーバーライドする

5.7で開発中なんだが、ログアウト後のリダイレクト先を変更するのどうしたらいいか調べてたら、ソースコードを読む感じIlluminate\Foundation\Auth\AuthenticatesUsersloggedOut()をオーバーライドするのがよさそうだったのだが、ググると同じクラスのlogout()をオーバーライドする例ばかり出てくる。

なぜかなーとgit blameしたところ、割と最近実装されたメソッドのようで、そのせいだろう。

Update AuthenticatesUsers.php · laravel/framework@e4a00e8 · GitHub

ということで、5.6.27以降ならloggedOut()が使えるので使おう。

<?php
# ...
class LoginController extends Controller
{
    use AuthenticatesUsers;
    # ...
    protected function loggedOut(Request $request)
    {
        return redirect(route('my_login'));
    }
    # ...
}

とかそんな感じでよさそう。

認証周りのカスタマイズの知見いろいろ溜まってきているので、そろそろ一回まとめたいなー。

LaravelのAuth::routes()で一部機能(ルート)を無効にする

Auth::routes()の本体である、Illuminate\Routing\Router::auth()を確認してて気付いたのでメモ。

<?php
# ...
Auth::routes([
    'register' => false,
    'reset'    => false,
]);
# ...

これで新規登録とパスワードリセットが無効にできる。管理者だけが扱うようなアプリケーションでは使いそう。

まあ、ドキュメントに書いてある

また、登録時のメールアドレスの確認を有効にするには、

<?php
# ...
Auth::routes([
    'verify' => true,
]);
# ...

5.7からの機能っぽい。まあこれもドキュメントに書いてある

なおルートの設定だけでは駄目っぽいので注意。

Composerのディレクトリが~/.config/composer以下になる場合

CentOS 7環境で、新規案件のためにLaravel入れたのだがlaravelコマンドが入ってない。~/.composer/vendor/binにパスは通ってるのになあ、とよく見てみると、~/.composer/vendor/bin自体がなかった。

もうちょっと調べてみると、~/.config/composerというのがある。どうも~/.composerではなくこちらにインストールされているようだ。

また、Laravelのドキュメントに以下のようなことが書いてあった。

グローバルなComposerのbinディレクトリを$PATHへ登録してください。このディレクトリはオペレーティングシステムにより場所が異なります。通常は、以下の場所です。

でも今まで同じ設定で動いてたしおかしいな、最近変更あったのかなとComposerのリポジトリ調べてみる。どうもこの辺で設定されている模様。

XDGがどうこうだとディレクトリが変わるらしい。さっそく環境変数をチェックしてみると、今まで使っていた環境(の一部、確認したのは)ではXDG_*という環境変数はなく、しかし今回の環境ではXDG_RUNTIME_DIR, XDG_SESSION_IDと2つ設定されいた。

どうもこれが原因のようだ。しかしこのXDGというのはそもそもなんなのか? そしてなぜ今まで設定されていなかったのに、今回設定されているのか?

後者の疑問はまだ解決していないが、前者については解決した。ArchLinuxのWikiに詳しい情報があるが、freedesktop関係の、ユーザディレクトリ内のディレクトリ構成の規格関係らしい。そういえばなんとなく聞き覚えがあるような。

解決策として、生のパスを入れるのではなく、Composerを叩いてパスを教えてもらうことにした。

export PATH=$(composer config --global --absolute home)/vendor/bin:$PATH

GitHubの公開鍵が勝手に消えていた件

Ansibleのauthorized_keyでGitHubの自分の公開鍵を指定するみたいな使い方してたので気付いたんだけど、昨日、登録していた公開鍵(1つ中1つ)が消えていたっぽい。

身に覚えはなく、ブラウザ履歴や作業ログで消えた時間帯を確認してみても、やっぱりその時間帯にはGitHubにアクセスしてすらいない。

となるとアカウント情報漏れでもしたかな、となるが、MFAこそかけてないもののパスワードは使い回さないし、それも考えにくい。

一応GitHubのSecurity historyを確認してみると、いくつかのログインと、問題の公開鍵の削除、ほかには慌てて再追加した際のログだけ残っていた。

f:id:xxmagai:20181205153238p:plain
GitHubのSecurityページ

ログインに関してはすべて自分のログインでほぼ確定。

さらに、ほかのログにはIPアドレスなどが記録されているのだが、公開鍵の削除については記録されていない。

f:id:xxmagai:20181205153242p:plain
public_key.createのログ

f:id:xxmagai:20181205153408p:plain
public_key.deleteのログ

もう一つ、この公開鍵を登録したのは、削除された日時のほぼ丸一年前である。

ググってもそんな情報はなかったが、おそらく未使用のまま一年経った公開鍵は削除される、とかそういう機能がこっそりあるのではないかという結論に達した。

追記: なにかの参考になるのかもしれないので、同じ現象っぽいものメモ

So about a month ago one of my public keys was removed..

Chat Log Server / Message 133053 in #github

追記2: 手動で削除した場合もIPアドレスは記録されないらしい

追記3: 一年で消えていた人がもう一人確認されたので、この結論でそれなりに正しそう

Vagrant + VirtualBox + vagrant-vbguestでCentOSでGuestAdditionsがうまく入らない場合

雑な記事注意。

Please install the Linux kernel "header" files matching the current kernel
for adding new hardware support to the system.
The distribution packages containing the headers are probably:
    kernel-devel kernel-devel-3.10.0-862.14.4.el7.x86_64
VirtualBox Guest Additions: Starting.
VirtualBox Guest Additions: Building the VirtualBox Guest Additions kernel modules.  This may take a
 while.

This system is currently not set up to build kernel modules.
Please install the Linux kernel "header" files matching the current kernel
for adding new hardware support to the system.
The distribution packages containing the headers are probably:
    kernel-devel kernel-devel-3.10.0-862.14.4.el7.x86_64
An error occurred during installation of VirtualBox Guest Additions 5.2.22. Some functionality may n
ot work as intended.
In most cases it is OK that the "Window System drivers" installation failed.
Redirecting to /bin/systemctl start vboxadd.service
Job for vboxadd.service failed because the control process exited with error code. See "systemctl st
atus vboxadd.service" and "journalctl -xe" for details.

こんな感じのログ出てたら、見るべきは一行目。

[vagrant@localhost ~]$ yum list installed | grep kernel
kernel.x86_64                    3.10.0-862.14.4.el7            @koji-override-1
kernel-headers.x86_64            3.10.0-957.1.3.el7             @updates
kernel-tools.x86_64              3.10.0-862.14.4.el7            @koji-override-1
kernel-tools-libs.x86_64         3.10.0-862.14.4.el7            @koji-override-1

多分こんな感じになってるので、

sudo yum update kernel

https://github.com/dotless-de/vagrant-vbguest/issues/311

確認してないけど、

kernel-devel-`uname -r`

https://github.com/dotless-de/vagrant-vbguest/blob/c0e47b9cb4e8936d270e952668aef78ac2d6e4e8/lib/vagrant-vbguest/installers/redhat.rb#L24

これがよくないのかな。