概念上の温泉

温泉や温泉宿に行きたいなと思う事は多々あるが、「概念上の温泉」に行きたいという人は居ないだろうか。私は概念上の温泉に行きたい。

温泉、温泉宿には私個人としては以下のイメージが有る。

  • ゆっくり温まれる。
  • それによって体中の疲れが取れる。
  • 露天風呂なら解放感の有る景色。
  • 肌触りの良い浴衣。
  • 座敷部屋にはみんな大好きな窓際の謎空間。
  • 豪華で美味しい料理。
  • 作業やら勉強やら集中できる。
  • 複数人で行ったらワイワイ楽しい。

では実際の温泉に行ってみるとどうだろうか。これは私の話なので完全に私の主観の話になる。

ゆっくり温まれる:
そもそも熱いのが苦手なので湯船に長時間浸かるのが苦手。せっかく温泉まで来ておいて5分有れば満足。粘っても15分かなという所である。

体中の疲れが取れる:
これは実際に取れるような気はしているのだが、気合を入れて温泉らしい温泉まで行くと帰る過程で結局疲れてしまう。家に着いてみると結局行く前より疲れている。また、温泉はどうしても多人数利用かつ水物なので、綺麗な温泉でもどこか温泉の成分ではなさそうなヌルヌル感があったり髪の毛が浮いていたりで、体にプラスのはずの場所でどうにも気になってしまう。レジオネラ菌もわんさか居るので本当に疲れきっている時は入らない方がいいと思う。

露天風呂なら解放感の有る景色 :
良い所はほんとに良いんだけども、それを観るには日中入らないといけない。日本は行った事のない土地の方がまだまだ圧倒的な私としては日中は普通に観光したいのである。

肌触りの良い浴衣 :
実際着てみるとあまりしっくりこないあの感じ。一応使うけど使わずTシャツで寝る事もままあり。

座敷部屋にはみんな大好きな窓際の謎空間 :
なんだか暗くて日中外出していると特に使わない。部屋の景色も良い宿なら朝は良い感じ。

豪華で美味しい料理 :
温泉旅館の食事、食べててきつい量でよくみんなあの量食べられるなと思います。海沿いそうでない関係なくやたら海老と蟹の登場率が高いですが、私はどちらもアレルギー。夕食の門限もうちょっと遅くなりませんかね。

作業やら勉強やら集中できる :
これはビジネスホテルでもそういう所結構有るのですが、正直もうちょっと照明明るくしてほしいですよね。

複数人で行ったらワイワイ楽しい :
楽しいは楽しいんだけど、夕食の門限が早いせいで結構手持無沙汰。とりあえずTV付けるかみたいな感じになりがち。そして楽しい旅行の後は虚無感に襲われがち。

と、こういう感じなのが温泉、温泉宿。ただ、文句ばっかり言っていますが温泉は嫌いではなく、温泉という概念は一番最初に上げたプラスのイメージのままなんですよね。温泉行きたい意欲も有る。実際に行ってみて実際にある程度良い所なんだけど、私の行きたかった温泉とは少し違う。温泉サイドが悪い訳でもなく悪いのは完全に私。

複数人で行くと皆は温泉を楽しんでいて、もちろん水を差したくは無いので微妙なポイントを直接口で列挙したりはしないが、どこか自分だけ楽しめていない気がしてくる。

ようするに「概念上の温泉」に行きたいんですよね。

Share this…

マイクロフレームワークっぽく使う Symfony 4 事始め 6 ~本番環境公開編~

Symfony 4 入門。前回の記事は以下

dev モードから prod モードに切り替える

第5回のこれまではずっと dev モードで開発してきました。dev モードでは例えば以下のような機能が提供されています。

  • Webページ下部に表示されるプロファイラ
  • 発行されたSQL全てがログに出力される(プロファイラ内でも確認できます)

前者は中身が筒抜けになり、後者は動作が遅くなりログサイズが爆発する原因になるのでどちらも本番環境として公開するには無効化しておきますよね。その場合は .env ファイル内での APP_ENV=dev の定義を APP_ENV=prod に変更する事で本番環境としてのモードに切り替える事が出来ます。もちろん .env.local で上書きする方法でも問題ありません。prod モードでは以下のような挙動の違いが有ります。

  • Webページ上にプロファイラが表示されない。
  • 発行されたSQLのログがログファイルに出力されない。
  • 設定ファイルの内 config/packages/dev 内の物がが読み込まれていた物は config/packages/prod 内の物が読み込まれるようになる。
  • ログのファイル名の dev の部分が prod になる。
  • キャッシュが自動的に更新されない。
  • bin\console server:run が使えない。

このうち「キャッシュが自動的に更新されない」件に関しては注意が必要です。プログラムのコードやビューテンプレートのコードを編集しても反映されなくなる場合が有ります。prod モードで運用している場合、改修のデプロイ後はキャッシュをクリアするようにしましょう。これはSymfonyのコマンドから実行する事が出来ます。

実行するには
php bin\console cache:clear
を実行します。

これでキャッシュが削除・更新されました。CIツールなどでデプロイを自動化しているような場合はこの操作を組み込んでおくといいんじゃないかと思います。

また、 bin\console server:run が使えなくなる件については確かに開発用の機能なのでそれも仕方ないかなという感じでは有りますが、ドキュメントルートになる public ディレクトリ内でPHPのビルトインサーバーを自分で起動してやれば dev モード時と同じようにビルトインサーバーで動作確認が可能です。

Share this…

マイクロフレームワークっぽく使う Symfony 4 事始め 5 ~ロギング編~

Symfony 4 入門。前回の記事は以下

Symfonyでのログ出力

Symfonyでのログ出力には基本的には monolog を使います。これはPSR-3に準拠するログ出力ライブラリで、この記事の第1回の時点で自動的に導入されています。また、DIコンテナによる注入にも初期状態で対応しているので、 Psr\Log\LoggerInterface を受け取るコンストラクタや関数を用意すればDIコンテナにより自動的に注入されます。

今回は第3回で作成したサービスクラス BooksService にログ出力を追加してみます。前回までの状態は以下。

<?php
namespace App\Service;

use App\Repository\BooksRepository;

class BooksService
{
    private $booksRepository;

    public function __construct(BooksRepository $booksRepository)
    {
        $this->booksRepository = $booksRepository;
    }

    public function bookDetail(int $book_id)
    {
        return $this->booksRepository->get($book_id);
    }
}

コンストラクタでLoggerInterfaceを受け取るようにします。受け取ったロガーを利用してログを出力します。

<?php
namespace App\Service;

use App\Repository\BooksRepository;

class BooksService
{
    private $booksRepository;

    /** @var Psr\Log\LoggerInterface logger */
    protected $logger;

    public function __construct(BooksRepository $booksRepository, \Psr\Log\LoggerInterface $logger)
    {
        $this->booksRepository = $booksRepository;
        $this->logger = $logger;
    }

    public function bookDetail(int $book_id)
    {
        $this->logger->log('info', 'book_id: ' . $book_id . ' の詳細データを取得して返します');
        return $this->booksRepository->get($book_id);
    }
}

ログを出力する関数には
log(‘ログレベル’, ‘メッセージ’)
の他にそれぞれのログレベルに対応した
emergency(‘メッセージ’)
alert(‘メッセージ’)
critical(‘メッセージ’)
warning(‘メッセージ’)
notice(‘メッセージ’)
info(‘メッセージ’)
debug(‘メッセージ’)
が利用できます。上に有るものが重要度の高いログになっています。

実際にログ出力を埋め込んだ bookDetail が呼びされる http://127.0.0.1:8000/books/detail/2/ にアクセスしてみます。

ログファイルは /var/log/dev.log に出力されています。

このファイル名の dev という部分は環境定義によるものなので、ユニットテスト実行時は test.log 、本番環境で動かす際は prod.log になります。

ログのローテーション

例えばLinux側にもログをローテーションするための仕組みは有り、それを利用してログファイルを管理してもいいですが、逆にプログラム側で最初からファイル名に日付を付けてほしいという場合も有るでしょう。それはmonologの設定で可能です。
config/packages/dev/monolog.yaml
は初期状態で以下のようになっています。

monolog:
    handlers:
        main:
            type: stream
            path: "%kernel.logs_dir%/%kernel.environment%.log"
            level: debug
            channels: ["!event"]
        # uncomment to get logging in your browser
        # you may have to allow bigger header sizes in your Web server configuration
        #firephp:
        #    type: firephp
        #    level: info
        #chromephp:
        #    type: chromephp
        #    level: info
        console:
            type: console
            process_psr_3_messages: false
            channels: ["!event", "!doctrine", "!console"]

typeの部分に指定されている stream がデフォルトの出力方法になっています。これを rotating_file に変更します。この状態でログを出力してみると

dev-2019-02-31.log と日付付きのファイル名で出力されるようになりました。

monologには他にもエラーをSlackに通知したりなどファイル出力に限らないログ出力機能を備えているようです。私自身も試せていませんが重要度の高いエラーは外部の監視に頼らずに通知できたりなども出来そうですね。

次回は本番環境での公開方法について。

Share this…